this post was submitted on 30 Mar 2024
223 points (98.3% liked)
Cybersecurity
5768 readers
96 users here now
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
Notable mention to [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.