[cetra3]

It just looks like stdx has copied stuff from crates and put it in a git repo.

It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?

[sheept]

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>" }

[testdelacc1]

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.

[worik]

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

Argumentum ad hominem, yuk

> the fundamental mistake of assuming that they’re trustworthy and we’d trust them no questions asked.

The author makes no such assumption, it is entirely your decision

> this repo is 100% AI slop,

That is an exaggeration. It is coded with AI help, as is almost everything these days

Agree, or disagree, that an anemic standard library is a problem, and crates.io is a glaring security risk and a looming catastrophe Kerkour is doing something about it

This is a start

[quacker]

AFAIK, Golang's module system (mentioned in the article) protects against this. From [1],

The revision must be an ancestor of one of the module repository’s branches or tags. This prevents attackers from referring to unapproved changes or pull requests.

1: https://go.dev/ref/mod

[alphabeta3r56]

This is hugely problematic behavior of github

[deeebug]

Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx

[tialaramex]

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.

[vlovich123]

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.

[oefrha]

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.

[FiloSottile]

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

[tptacek]

Hah, length-extension and CBC mode, famous NIST backdoors.

[graypegg]

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.

[tptacek]

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.

[worik]

I am a supporter of Kerkour's efforts

> are Rust developers going to seriously entertain an alternative "standard library" curated by one developer.

No. Absolutely not

But this is a start. Join the effort. Help them

[lenkite]

Can someone explain to me how is that Java/Kotlin ecosystem has managed to use maven repositories for 3 decades now with very few of these issues ?

[worik]

> As in why would I trust a random git repo

It is one repo to trust, rather than hundreds

That is the reason

[simonask]

The reason is invalid.

[bel8]

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.