> So, I have opinions about criticism of crates.io for supply-chain attacks.
I also strongly disagree with most of the criticisms of crates.io, but…
We are owed supply chain security. The moment a group says “use our stuff for critical projects” they take on some baseline level of responsibility for making things secure.
You cannot offer a taxi service in a car that is not fit for the road, and then just shrug when it crashes a people get hurt.
The good news is the people behind crates.io and the Rust ecosystem care about security. They have given conference talks about what they are doing behind the scenes. Features like Trusted Publishing are a huge step in the right direction.
As far as I can tell, the issue is not with the crates.io team, but funding and incentives as a whole. We all rely on critical infrastructure like package managers, but not many are willing to fund big security improving features.
> The moment a group says “use our stuff for critical projects” they take on some baseline level of responsibility for making things secure
Every popular open-source license explicitly states that exactly the opposite is true:
Apache license:
"Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND"
GPL v2:
"THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND"
Mozilla license:
"Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall any Contributor, or anyone who distributes Covered Software as permitted above, be liable to You for any direct, indirect, special, incidental, or consequential damages of any character"
BSD license (both 2 and 3 clause versions):
"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES"
MIT license:
"THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND"
You are and have always been on your own when using open-source software. Nobody owes you anything.
Owed by whom, though? That seemed to the point of the article - "owed" implies some kind of debt or obligation. Free software developers don't have any obligations to anyone else.
> You cannot offer a taxi service in a car that is not fit for the road, and then just shrug when it crashes a people get hurt.
The problem is that there's no overt way to tell whether the "car" (code) you're looking at is someone's experimental go-kart made by lashing a motor to a few boards, or a well tested and security analyzed commercial product, without explicitly doing those processes on your own.
The problem is all the go-kart hobbyists who make moderately popular go-kart designs end up being asked for all sorts of commercial territory requirements.
The people on the consuming end think "reliability is their job!" and try to force all their requirements and obligations onto the go-kart makers, which usually doesn't end well.
You really can't compare crates to a taxi service and I think the article lays out the reasoning nicely. The people running crates are a small team of mostly volunteers offering a free service. If someone offered a free taxi service as a small organization of volunteers then they could easily be forgiven for not having the same standards that a regulated for-profit business would.
It's the gift of open source: Nobody owes you anything except the source code. Any and all guarantees must be via written contracts. Nobody owes you a secure supply chain until there is a contract stating such.
I feel like they could do a better job, though. In the postmortems of incidents you often hear it's because some maintainer got hit by the perfect phishing attack at the right time and they got tricked into entering password and TOTP into a phishing site. If that is so, why are we still allowing phishable credentials for logging into package repositories?
> An oft brought-up issue is that the code on crates.io and in Git don’t always match.
I don't understand why this is the case. Imo it should be a basic expectation, that a given package is built from a frozen, dedicated git commit (represented by hash), and a likewise frozen build script. The build should be deterministic, so that the end result should be hashed, and the build script ran by some trusted vendor (maybe github), and the end result hashed.
If there's any doubt about the integrity of a package, the above process can be repeated, and the artifacts checked against a known hash.
Sorry I'm just gonna copy some of this directly from tweets about sandboxing that I'd written.
I think it is a mistake to say "cargo build does not need to be sandboxed because cargo test is not". A very tricky part of sandboxing is sandboxing code you don't own. I own what code runs in tests, I do not own what code runs in cargo/ build scripts.
I can take responsibility for isolation in test/ci/prod. Those are tractable problems because I can design my tests/prod code to be friendly to sandboxing. I can not do that with build scripts or proc macros, I can't actually do much at all.
The solution for "sandbox cargo" ends up being "sandbox the entire dev environment", which is a very difficult problem to solve - you lose tons of performance, UX, and the security is lacking due to how much gets placed into the sandbox.
I strongly feel that cargo is in a much better position to help me out here. I can't even know if an update to a crate happened that suddenly added a build script without additional tooling.
As for typosquatting,
> If you think you can remember the URLs for each package you use, you’re probably wrong.
Most people aren't using urls so I don't get this. The issue is typing cargo add reqwest. Typosquatting algorithms solve this.
I did some math.
If crates.io had adopted a policy of "no crates within edit distance of one", 15% of crates would have been blocked across all time.
+Exception for same author: 14%
+Exclude <=4: 9%
+Swap from edit distance to actual typo detection algorithm: 5%
5% of crates would have needed a name change across all time. That number will likely decrease drastically as existing names are taken.
Yes, Rust needs radically more funding in these areas. Companies need to step up. Sandboxing, typo squatting, better auditing tools (ie: I need to know when cargo udpate adds a dep with a new build script, etc), TUF, etc, all need to be priorities.
> Making Linux distro maintainers responsible instead (duplicating work).
As this has been one (but not the only) of my arguments, the wording is a little off, I think. Rather, the argument is really also about using "stable" rather than bleeding edge software and doing some third-party vetting in-between; cf. also
We do all recognize that for the last 5+ years we have been repeatedly scolded that the safest thing you could do for software was just “switch to Rust”. I personally didn’t buy it because software safety is way more complex than automatic bounds checking. But the trap was set and here we are. I look forward to seeing this being resolved and for the next generations of language platforms to learn from this and start new.
I like how the Go team does things. For example, this is only one part of it, but the Go checksum database seems like a pretty good solution for making sure that a path and version reliably maps to the same source code.
This is bad by being a categorical statement. But it's also a bad categorical statement because it's like saying nobody owes you being able to assume your car has airbags and seatbelts that meet high standards.
"No one owes you car safety. You're responsible for not crashing - cars give you all the tools you need: brakes, steering, lights..."
Disappointing to hear this from a Rust programmer, who should really know better. Although they say they aren't even a programmer so I guess that makes sense.
Wtf does this even mean - its like saying nobody owes me asbestos-free food. There sure is a demand for it, and certain customers find as mostly not backdoored supply chain good enough, and they wont do business in your ecosystem if you cant give them that.
This is the classic open-source problem. Open source manintainers feel like they don't owe anything for people making money with their software for free, meanwhile customers want working code, and are willing to pay for it, your software being free is a nice perk.
As much as I understand the maintainers' standpoint, history has proven the customer is always right, and the only projects that have staying power are the ones that meet the quality bar.
88 comments
> So, I have opinions about criticism of crates.io for supply-chain attacks.
I also strongly disagree with most of the criticisms of crates.io, but…
We are owed supply chain security. The moment a group says “use our stuff for critical projects” they take on some baseline level of responsibility for making things secure.
You cannot offer a taxi service in a car that is not fit for the road, and then just shrug when it crashes a people get hurt.
The good news is the people behind crates.io and the Rust ecosystem care about security. They have given conference talks about what they are doing behind the scenes. Features like Trusted Publishing are a huge step in the right direction.
As far as I can tell, the issue is not with the crates.io team, but funding and incentives as a whole. We all rely on critical infrastructure like package managers, but not many are willing to fund big security improving features.
> The moment a group says “use our stuff for critical projects” they take on some baseline level of responsibility for making things secure
Every popular open-source license explicitly states that exactly the opposite is true:
Apache license: "Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND"
GPL v2: "THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND"
Mozilla license: "Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall any Contributor, or anyone who distributes Covered Software as permitted above, be liable to You for any direct, indirect, special, incidental, or consequential damages of any character"
BSD license (both 2 and 3 clause versions): "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES"
MIT license: "THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND"
You are and have always been on your own when using open-source software. Nobody owes you anything.
> You cannot offer a taxi service in a car that is not fit for the road, and then just shrug when it crashes a people get hurt.
The problem is that there's no overt way to tell whether the "car" (code) you're looking at is someone's experimental go-kart made by lashing a motor to a few boards, or a well tested and security analyzed commercial product, without explicitly doing those processes on your own.
The problem is all the go-kart hobbyists who make moderately popular go-kart designs end up being asked for all sorts of commercial territory requirements.
The people on the consuming end think "reliability is their job!" and try to force all their requirements and obligations onto the go-kart makers, which usually doesn't end well.
> We are owed supply chain security.
Careful, requiring that might get you completely unmaintained software instead.
> An oft brought-up issue is that the code on crates.io and in Git don’t always match.
I don't understand why this is the case. Imo it should be a basic expectation, that a given package is built from a frozen, dedicated git commit (represented by hash), and a likewise frozen build script. The build should be deterministic, so that the end result should be hashed, and the build script ran by some trusted vendor (maybe github), and the end result hashed.
If there's any doubt about the integrity of a package, the above process can be repeated, and the artifacts checked against a known hash.
This would make builds fully auditable.
I think it is a mistake to say "cargo build does not need to be sandboxed because cargo test is not". A very tricky part of sandboxing is sandboxing code you don't own. I own what code runs in tests, I do not own what code runs in cargo/ build scripts.
I can take responsibility for isolation in test/ci/prod. Those are tractable problems because I can design my tests/prod code to be friendly to sandboxing. I can not do that with build scripts or proc macros, I can't actually do much at all.
The solution for "sandbox cargo" ends up being "sandbox the entire dev environment", which is a very difficult problem to solve - you lose tons of performance, UX, and the security is lacking due to how much gets placed into the sandbox.
I strongly feel that cargo is in a much better position to help me out here. I can't even know if an update to a crate happened that suddenly added a build script without additional tooling.
As for typosquatting,
> If you think you can remember the URLs for each package you use, you’re probably wrong.
Most people aren't using urls so I don't get this. The issue is typing
cargo add reqwest. Typosquatting algorithms solve this.I did some math.
If crates.io had adopted a policy of "no crates within edit distance of one", 15% of crates would have been blocked across all time.
+Exception for same author: 14%
+Exclude <=4: 9%
+Swap from edit distance to actual typo detection algorithm: 5%
5% of crates would have needed a name change across all time. That number will likely decrease drastically as existing names are taken.
Yes, Rust needs radically more funding in these areas. Companies need to step up. Sandboxing, typo squatting, better auditing tools (ie: I need to know when
cargo udpateadds a dep with a new build script, etc), TUF, etc, all need to be priorities.> Making Linux distro maintainers responsible instead (duplicating work).
As this has been one (but not the only) of my arguments, the wording is a little off, I think. Rather, the argument is really also about using "stable" rather than bleeding edge software and doing some third-party vetting in-between; cf. also
https://news.ycombinator.com/item?id=47585172
https://go.dev/ref/mod#checksum-database
Disappointing to hear this from a Rust programmer, who should really know better. Although they say they aren't even a programmer so I guess that makes sense.
This is the classic open-source problem. Open source manintainers feel like they don't owe anything for people making money with their software for free, meanwhile customers want working code, and are willing to pay for it, your software being free is a nice perk.
As much as I understand the maintainers' standpoint, history has proven the customer is always right, and the only projects that have staying power are the ones that meet the quality bar.