4 ms·

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 r

by cetra3 4mo ago

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?

graypegg 4mo ago
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.
deeebug 4mo ago
Looks like it's that, plus vibe coding (in areas like crypto!) - https://kerkour.com/stdx https://kerkour.com/stdx
- FiloSottile 4mo ago
  Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor https://kerkour.com/nist-cryptography-backdoor (I’m more worried about judgement calls than implementation correctness, it’s not about AI.)
  - tptacek 4mo ago
    Hah, length-extension and CBC mode, famous NIST backdoors.
- tialaramex 4mo ago
  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.
  - oefrha 4mo ago
    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.
  - vlovich123 4mo ago
    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.
bel8 4mo ago
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.
sheept 4mo ago
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 4mo ago
  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 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.
  - joshka 4mo ago
    [flagged]
  - worik 4mo ago
    > 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
- alphabeta3r56 4mo ago
  This is hugely problematic behavior of github
- 4mo ago
tptacek 4mo ago
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 4mo ago
  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
worik 4mo ago
> As in why would I trust a random git repo It is one repo to trust, rather than hundreds That is the reason
- simonask 4mo ago
  The reason is invalid.
lenkite 4mo ago
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 ?

by cetra3 4mo ago

graypegg 4mo ago

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.

deeebug 4mo ago

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

FiloSottile 4mo ago
Uh, yeah, this is not the writing of someone with the experience to maintain a cryptography toolkit: https://kerkour.com/nist-cryptography-backdoor https://kerkour.com/nist-cryptography-backdoor (I’m more worried about judgement calls than implementation correctness, it’s not about AI.)
- tptacek 4mo ago
  Hah, length-extension and CBC mode, famous NIST backdoors.
tialaramex 4mo ago
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.
- oefrha 4mo ago
  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.
- vlovich123 4mo ago
  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.

bel8 4mo ago

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.

sheept 4mo ago

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 4mo ago
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 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.
- joshka 4mo ago
  [flagged]
- worik 4mo ago
  > 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
alphabeta3r56 4mo ago
This is hugely problematic behavior of github
4mo ago

tptacek 4mo ago

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 4mo ago
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

worik 4mo ago

> As in why would I trust a random git repo It is one repo to trust, rather than hundreds That is the reason

simonask 4mo ago
The reason is invalid.

lenkite 4mo ago

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 ?