Stdx, Rust's extended standard library
kerkour.com
Stdx, Rust's extended standard library
1–10 of 19 posts
Re: Stdx, Rust's extended standard library
#2This is not even the first project like this named stdx.
While many people say they want something like this, in practice, most people prefer the status quo. Maybe this time will be different, we’ll see!
Re: Stdx, Rust's extended standard library
#3A single guy vibecoded a “stdlib” with Deepseek?
Re: Stdx, Rust's extended standard library
#4A single guy vibecoded a “stdlib” with Deepseek?
Seems like he forked a bunch of already-existing crates and then added some vibecoding on top.
Re: Stdx, Rust's extended standard library
#5This is a collection of forked open source crates bundled together with open model vibe coding?
> the code written by AI is more robust than by humans because more edge cases are tested.
This is at least a mildly concerning take to see in a blog post announcing a solution to supply chain security.
It seems like this boils down to: don’t trust the original authors to maintain the packages they wrote, trust me and my LLM instead.
Re: Stdx, Rust's extended standard library
#6Personally I think this is the wrong solution. I want crowd-sourced auditing for the existing ecosystem, not forked/vibecoded alternatives.
Re: Stdx, Rust's extended standard library
#7> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!).
> But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof.
> These test vectors, combined with the official specification documents of the crypto algorithms were rather effective to guide the coding agents and avoid the worst hallucinations.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
The first rule about implementing in crypto is don't roll your own. But if you do, the second rule is that you have to actually deeply understand every algorithm you implement, and every interaction between every system they touch. The appropriate ratio between time spent reading research papers and time spent writing production code is well north of 100:1. You cannot get crypto right by doing it one small piece at a time. You cannot black box it by using tests. There is not a test for every corner case, the corner cases are lethal, and if your library is ever actually used for anything even remotely important, there absolutely will be attackers constructing those corner cases to attack your system.
The short version is that absolutely no-one should ever use this.
Re: Stdx, Rust's extended standard library
#8This is a collection of forked open source crates bundled together with open model vibe coding? > the code written by AI is more robust than by humans because more edge cases are tested. This is at least a mildly concerning take to see in a blog post announcing a solution to supply chain security. It seems like this boils down to: don’t trust the original authors to maintain the packages they wrote, trust me and my L…
And just decided to relicense those forks with no real regard.
Also, it’s a loooong way from the self-contained goal—- there are a lot of third-party crates as dependencies still.
Yikes.
Re: Stdx, Rust's extended standard library
#9> Cryptographic code is famously hard, with many, many footguns haunting unsuspecting developers (and even experts!). > But, cryptography also has something that you likely won't find in any other domain: an extensive public collection of test vectors, particularly for edge cases. Every algorithm specification come with a basic suite of test vectors, but there are also community-built wonders such as Wycheproof. > Th…
With crypto publicly available tests come in form of KATs (Known Answer Tests), it ensures that the implementation works for certain inputs and thus it'll probably work for the whole domain, but it does not protect from subtle forms of weaknesses such as side channels.
The short version is that absolutely no-one should ever use this.
Ditto.
Re: Stdx, Rust's extended standard library
#10...but why?
Seriously, this needs some more justification:
> Only big and well-funded organization are able to build the internal tooling and libraries requireed to securely ship large Rust projects.
Leaving aside the (real!) problems other commenters have highlighted, before even getting to those issues I have a small foundational question:
Is this actually a real problem?