3 ms·

> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything The point is someone needs to curate those "deps". It's no

by ajross 8mo ago

> Those deps have to come from somewhere, right? Unless you're actually rolling your own everything The point is someone needs to curate those "deps". It's not about rolling your own, it's about pulling standard stuff from standard places where you have some hope that smart people have given thought to how to audit, test, package, integrate and maintain the "deps". NPM and Cargo and PyPI all have this disease (to be fair NPM has it much worse) where it's expected that this is all just the job of some magical Original Author and it's not anyone's business to try to decide for middleware what they want to rely on. And that way lies surprising bugs, version hell, and eventually supply chain attacks. The curation step is a critical piece of infrastructure: thing things like the Linux maintainer hierarchy, C++ Boost, Linux distro package systems, or in its original conception the Apache Foundation (though they've sort of lost the plot in recent years). You can pull from those sources, get lots of great software with attested (!) authorship, and be really quite certain (not 100%, but close) that something in the middle hasn't been sold to Chinese Intelligence. But the Darwinian soup of Dueling Language Platforms all think they can short circuit that process (because they're in a mad evangelical rush to get more users) and still ship good stuff. They can't.

lesuorac 8mo ago
I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM). Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/ https://docs.rs/regex/latest/regex/ [2]: https://github.com/rust-lang/regex https://github.com/rust-lang/regex
- ajross 8mo ago
  > I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. That's not the requirement though! Curation isn't about packaging, it's about independent (!) audit/test/integration/validation paths that provide a backstop to the upstream maintainers going bonkers. > But what's the threat model here. A repeat of the xz-utils fiasco, more or less precisely. This was a successful supply chain attack that was stopped because the downstream Debian folks noticed some odd performance numbers and started digging. There's no Debian equivalent in the soup of Cargo dependencies. That mistake has bitten NPM repeatedly already, and the reckoning is coming for Rust too.
  - Ygg2 8mo ago
    > A repeat of the xz-utils fiasco Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand. > because the downstream Debian folks Not sure what you mean by this, but this was discovered by a Postgres dev running bleeding edge Debian. No Debian package maintainer noticed this. > There's no Debian equivalent How would Debian approach help? Not even their maintainers could sniff this one. There exists a sort of extended std library of Rust dep. But no one is using it.
    - ajross 8mo ago
      > Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue. > Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand. With all respect, this is an awfully obtuse take. The problem isn't the "package manager", it's (and I was explicit about this) it's the lack of curation. It's true that xz-utils didn't use NPM. The point is that NPM's lack of curation is, from a security standpoint, isomorphic to not having any packaging regime at all, and equally dangerous. > a Postgres dev running bleeding edge Debian Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors. No one does that for NPM. There is no Cargo Rawhide or NPM Testing operated by attested organizations where new software gets quarantined and validated. If the malicious authors of your upstream dependencies want you to run backdoored software, then that's what you're going to run.

by ajross 8mo ago

lesuorac 8mo ago

I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. But what's the threat model here. Does it matter that the Rust STD library doesn't expose say "Regex" functionality forcing you to depend on Regex [1] which is also written by the same people who write the STD library [2]? Like if they wanted to add a back-door in to Regex they could add a backdoor into Vec. Personally I like the idea of having a very small STD library so that it's focused (as well as if they need to do something then it has to be allowed by the language unlike say Go Generics or ELM). Personally I think there's just some willful blindness going on here. You should never have been blindly trusting a giant binary blob from the std library. Instead you should have been vendoring your dependencies and at that point it doesn't matter if its 100 crates totaling 100k LOC or a singular STD library totaling 100k LOC; its the same amount to review (if not less because the crates can only interact along `pub` boundaries). [1]: https://docs.rs/regex/latest/regex/ https://docs.rs/regex/latest/regex/ [2]: https://github.com/rust-lang/regex https://github.com/rust-lang/regex

ajross 8mo ago
> I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. That's not the requirement though! Curation isn't about packaging, it's about independent (!) audit/test/integration/validation paths that provide a backstop to the upstream maintainers going bonkers. > But what's the threat model here. A repeat of the xz-utils fiasco, more or less precisely. This was a successful supply chain attack that was stopped because the downstream Debian folks noticed some odd performance numbers and started digging. There's no Debian equivalent in the soup of Cargo dependencies. That mistake has bitten NPM repeatedly already, and the reckoning is coming for Rust too.
- Ygg2 8mo ago
  > A repeat of the xz-utils fiasco Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand. > because the downstream Debian folks Not sure what you mean by this, but this was discovered by a Postgres dev running bleeding edge Debian. No Debian package maintainer noticed this. > There's no Debian equivalent How would Debian approach help? Not even their maintainers could sniff this one. There exists a sort of extended std library of Rust dep. But no one is using it.
  - ajross 8mo ago
    > Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue. > Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand. With all respect, this is an awfully obtuse take. The problem isn't the "package manager", it's (and I was explicit about this) it's the lack of curation. It's true that xz-utils didn't use NPM. The point is that NPM's lack of curation is, from a security standpoint, isomorphic to not having any packaging regime at all, and equally dangerous. > a Postgres dev running bleeding edge Debian Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors. No one does that for NPM. There is no Cargo Rawhide or NPM Testing operated by attested organizations where new software gets quarantined and validated. If the malicious authors of your upstream dependencies want you to run backdoored software, then that's what you're going to run.