upvote
Plus, with forks anyone can publish a commit accessible from the main repo, so one could disguise a malicious version of stdx by forking the repo, pushing their charges, then setting the rev:

    base64 = { git = "https://github.com/rust-stdx/stdx", rev = "<sha1 of malicious commit in fork>" }
reply
This is hugely problematic behavior of github
reply
This comment needs to be higher up. The author styles themselves as a cybersecurity expert, but makes the fundamental mistake of assuming that they’re trustworthy and we’d trust them no questions asked. Software security isn’t based on blind trust like this. I’m surprised an expert can’t see that.

The other reason I don’t trust them is because this repo is 100% AI slop, even for crypto code. He posted it on /r/rust where every comment was highly negative - https://www.reddit.com/r/rust/s/4I4Xc7x7ec. The thread was removed by a moderator with the note:

Please, stop posting articles from kerkour.com.

The blog has been on a downward spiral for years, it's doomed, let it go.

reply
[flagged]
reply
> As in why would I trust a random git repo

It is one repo to trust, rather than hundreds

That is the reason

reply
Yeah that confused me for a second too. I think they're talking about stdx as a single package, even though it contains multiple crates. If you wanted to install a crate from stdx specifically, you'd use this git URL but if you wanted any other package, you'd use another git URL controlled by that project.

So as I understand it, they're not suggesting that we pile many packages into 1 git repo as a sort of pseudo-crates.io, they're just promoting the fact that you can install a package directly from a git URL, rather than using a crate name on a registry.

What seems weird about that model to me is that dependancies will not sync between these individual packages. If package A chooses the canonical git URL for package C, and package B uses a self-hosted version of package C instead, you have two versions of package C.

reply
Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx
reply
The whole "There are test vectors so we know it's correct" is a strong sign that this isn't actually safe to use and that indeed the people who built it (to the extent people actually did build it) have no idea what they're doing.
reply
For anyone wondering why, test vectors only cover “did the encryption work”. It does not cover “did you maintain constant time guarantees” to prevent against side channel attacks as an example. Crypto is filled with all kinds of such pitfalls that aren’t covered by conformance tests.

Hence “strong sign this is built by people who have no idea what they’re doing” is accurate.

reply
To save you a read of the original while still having enough context, here's the whole section on crypto:

> crypto: spec and test-driven development to the rescue

> 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.

> Cost: ~ $30

> Time: multiple days of part-time work.

> I'm under no illusion that the crypto crate is currently bug-free, but if my experience told me anything, it's that even experienced programmers are shipping bugs in crypto libraries. So, for similar outcomes, but using 1/100 of the time and at maybe 1/1000 of the cost, I think it's a clear demonstratin of AI's effectiveness.

Yeah, terrifyingly clueless, don't use.

reply
Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor

(I’m more worried about judgement calls than implementation correctness, it’s not about AI.)

reply
Hah, length-extension and CBC mode, famous NIST backdoors.
reply
The author is trying to make "stdx" a thing, and content like this (I'm not dunking on it) is what you write when you're trying to reinforce the idea that it's a thing.

The big question about this project isn't its distribution, it's the core question it posed when it was first announced: are Rust developers going to seriously entertain an alternative "standard library" curated by one developer.

reply
One upside I can think is that it is easier to trust and verify one repo than hundreds.

And the chances of a rogue actor or id theft reduce drastically.

reply