Wyre@sh.itjust.works to Cybersecurity@sh.itjust.worksEnglish · 2 年前GitHub disables XZ Repositorywww.phoronix.comexternal-linkmessage-square19fedilinkarrow-up1228
arrow-up1228external-linkGitHub disables XZ Repositorywww.phoronix.comWyre@sh.itjust.works to Cybersecurity@sh.itjust.worksEnglish · 2 年前message-square19fedilink
minus-squaresugar_in_your_tea@sh.itjust.workslinkfedilinkEnglisharrow-up1·2 年前Awesome! It’s impressive that it’s decently close in performance with no unsafe code. Thanks for your hard work! And that Go implementation is pretty fast too! That’s quite impressive.
minus-squareKilling_Spark@feddit.delinkfedilinkEnglisharrow-up1·2 年前Sadly it does have one place with unsafe code. I needed a ringbuffer with an efficient “extend from within” implementation. I always wanted to contribute that to the standard library to actually get to no unsafe.
minus-squaresugar_in_your_tea@sh.itjust.workslinkfedilinkEnglisharrow-up1·2 年前Ah, I saw a PR from like 3 years ago that removed it, so it looks like you added it back in for performance. Have you tried contributing it upstream? I’m not a “no unsafe” zealot, but in light of the xz issue, it would be nice.
minus-squareKilling_Spark@feddit.delinkfedilinkEnglisharrow-up1·2 年前 Have you tried contributing it upstream? I didn’t yet just because I didn’t get around to it (and because I am not sure the std lib even wants this feature). I’m not a “no unsafe” zealot, but in light of the xz issue, it would be nice. I don’t think the two relate. I wouldn’t drop any dependency, the ringbuffer is implemented in the same repo.
minus-squaresugar_in_your_tea@sh.itjust.workslinkfedilinkEnglisharrow-up1·2 年前Yeah, they’re not really related. I’m just thinking there might be more scrutiny on compression due to the exploit. That said, yours doesn’t support encoding anyway, so it’s kind of moot.
Awesome! It’s impressive that it’s decently close in performance with no unsafe code. Thanks for your hard work!
And that Go implementation is pretty fast too! That’s quite impressive.
Sadly it does have one place with unsafe code. I needed a ringbuffer with an efficient “extend from within” implementation. I always wanted to contribute that to the standard library to actually get to no unsafe.
Ah, I saw a PR from like 3 years ago that removed it, so it looks like you added it back in for performance.
Have you tried contributing it upstream? I’m not a “no unsafe” zealot, but in light of the xz issue, it would be nice.
I didn’t yet just because I didn’t get around to it (and because I am not sure the std lib even wants this feature).
I don’t think the two relate. I wouldn’t drop any dependency, the ringbuffer is implemented in the same repo.
Yeah, they’re not really related. I’m just thinking there might be more scrutiny on compression due to the exploit.
That said, yours doesn’t support encoding anyway, so it’s kind of moot.