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.
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.
I know that doesn’t apply 1:1 to software, but the point is less about individual OSS projects and more about the hosted service of package registries, which do have people & money behind them.
Npm, for example, is owned by Microsoft (through GitHub). MS has huge amounts of money. They could be scanning for malware on upload and adding so many more security mechanisms. But they don’t.
Developers have an ethical responsibility but that doesn’t mean they should be legally accountable for genuine mistakes.
If I open source something, I am not your parent, if you decide to wing it just because it is open source that is your problem not mine.
You are not obligated to use anything anyone open sources. If you can't take responsibility for your own actions that's on you, not the person who open sourced it - that is what generally all the licenses state to begin with.
We are talking about developers having ethical ownership for communicating their project responsibly.
That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready.
And it’s disingenuous to spin this as “only trillion dollar companies use open source” because we all know that isn’t even remotely true.
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.
If you’re using a security package and it isn’t either a shim over an existing API (eg porting a C-library to a non-C language) or it fails to provide evidence of independent audits, then steer clear or it.
Most other domains are generally much easier for the developer to audit.
However I will say in an age of AI, it will become much easier than it already is to inadvertently pull bad packages.
In arch Linux, I trust the base repositories more than AUR.
1. Consumer protection, product safety, and liability.
2. Truth in advertising, fraud prevention, etc.
3. Freedom of expression, association, publication, etc.
There is legal precedence in concepts like "attractive nuisance" to put the liability on a producer or owner not to allow the naive public to encounter their dangerous constructions. But we generally allow for media to illustrate such things, i.e. you can depict dangerously unprotected swimming pools, booby-traps, or poisoned food distribution in a book, image, or movie. You get in trouble when you put any of this in the real world though.
This is particularly confusing with software because of its duality as being something like speech or media that we can publish and also something like tools or products that can be manufactured, distributed, and consumed with observable results in the real world.
Who is liable when the unsafe software is distributed and converted from speech into machine action by naive end users?
If you actively advertise and give away free food, there is a baseline assumption that you are at least cooking the food in sanitary conditions.
If people get sick after eating the food you gave them, you can’t just shrug and say it was free.
Any software you use with this clause, "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."
Already attests that the authors do not offer guarantees that the software will have the features you need, supply chain security or otherwise.
Blindly pulling updates from providers that offer you no contractual guarantees has to be gross negligence right?
The software is provided as is.
In the context of commercial food safety, we can have your discussion. Outside of commercial activity, you are accepting all risk with consumption of home baked goods. There are no guarantees around cooking area cleanliness, hygiene, status of ingredients, cooking methods, or any of those guarantees. No legal system with give you a standing to levy an action against someone in that case. Especially if ultimately, you elected to use that code/eat the treat. Now, if you can prove, mal-intent; they made a batch of brownies, other people ate brownies, but you specifically got sick after being served a sample by the individual; then you might get some extra attention, but that has a much higher bar of proof.
So yes. If you get the one bad brownie out of a batch I cook in my kitchen for the potluck you ate at knowing the risks, that's on you. I'd be mortified personally if it happened, but in all likelihood it was accidental. You aren't paying me, and I'm doing it because I want to, but everyone does ultimately accept some risk.
Same goes for physical manufacturing supply chains too! QA is WAY more strictly enforced through contracts and vendor agreements with pre-defined, agreed upon, and often voluntarily entered into audit processes defined in mutually entered into contracts. It's the QA groups task at a step of the process to audit inputs for conformity to agreed upon Quality Standards, and to assure, and guarantee through Quality Control the specs are met for the next link in the chain, and to be audited for such compliance by the QA group at the next link in the supply chain. The key here is a shared, compelling, and formalized commercial interest, solidified through shared investment by all parties in the chain. That does not exist in FLOSS. The vast majority will never pay you, or enter into any supportive relationship with you. In fact, most code is written to the standard of "I know how I'm going to use it". If I'm not dealing with OWASP top 10 or what have you in my context, I'm not making my code handle it. Not my problem. I also don't have guilt sharing it either. You use it in a way that it's dangerous to you, that is on you.
If this angers you, fine. But while I personally understand where you are coming from, I've been around long enough to know that it is absolutely the case that if you want baseline duty of care to everyone who comes across this product regardless of my purposes I designed it for... There will be no more shared code. Nor will we share specs either.
IANAL.
If I mix some ecoli into your drink mix, I did this on purpose. You just don’t know it until it is too late.
Are you liable for allowing this to happen?
Open source is fundamentally a gift culture from the authors: here's a thing. You can use it for free; it may or may not meet your needs; but I do not owe you anything either way.
The last person, I think, most clearly, does "owe" you supply-chain security, in the sense that he bears moral (and ought to be made to bear professional) responsibility for any adverse consequences you may suffer from its lack, though in practice he will probably often protest that he couldn't do anything about it because it's not like he is developer. Whether the developer also owes it is a more interesting question, and I think it greatly depends on what attitude he takes towards the evangelist (does he consider him a nuisance who makes implicit promises the developer is uninterested in delivering, or an ally who raises the dev's profile?).
Long ago, I remember seeing a cartoon which involved a tag-team of two people robbing a third, with A pointing a gun at C and saying "give your money to B", while B comments "I'm really just standing here, but I figure it's best if you do as he says". I'm not sure what exact piece of day-to-day politics this was made to comment on (though it was probably some or another flavour of political violence), but it seems somewhat applicable here as well. The lines just become "accept the supply chain, or suffer my public ridicule" and "I'm just providing the software 'as-is', but you probably should do as he says".
This is doing a lot of heavy lifting, and not really valid as a categorical statement. It's important to narrow the context because "Free software developers" are ultimately still people or organizations that fall into our established systems. There is no specific purchase contract between the provider and user, so unlike commercial software that supply-side obligation is not explicit. There's typically a license that tries to legal-away any responsibility, and this is not so clear-cut. Free software is not found at the side of the road without any providence. It's usually the product of one or more legal entities, promoted, it's use encouraged and maintenance & delivery can be implied by the actions of the developers. All of these things carry varying degrees of obligation within legal, cultural and social frameworks. We try to reduce this down to "no obligations" or "expectation to support for free in perpetuity" but no binary position is accurate.
What if you were distributing food, and a farmer who supplied rice to one of the manufacturers of the components of your food grew that rice on a field that was contaminated with arsenic?
What does binary tarballs have to do with it? Whether the package is in source form or in binary form, a long dependency chain attack is equally likely to succeed.
Don’t get me started on everyone being git@github.com…
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.
You're doing exactly what the other poster in a different thread above said is happening:
>>> Long ago, I remember seeing a cartoon which involved a tag-team of two people robbing a third, with A pointing a gun at C and saying "give your money to B", while B comments "I'm really just standing here, but I figure it's best if you do as he says". I'm not sure what exact piece of day-to-day politics this was made to comment on (though it was probably some or another flavour of political violence), but it seems somewhat applicable here as well. The lines just become "accept the supply chain, or suffer my public ridicule" and "I'm just providing the software 'as-is', but you probably should do as he says".
One party hurls insults at those who don't want to switch, the other party (you) is going "I'm just standing here offering the download, but you should probably do what he says".
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.
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
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.
"Here's a free car on a parking lot. You can take it if you want it for free. The car hasn't been inspected and there are no guarantees that it's road-worthy".
I think this is perfectly acceptable in most countries and I doubt you'd have any standing to sue if the car turns out to have safety issues.
Then feel fucking free to pay the Rust community to audit the software.
Oh, that's too much for you. I see how it is.
I sound a bit pissy, but the amount of entitlement that occurs when things are free is off the charts in this thread.
In any case just paying people do to a ton of auditing is clearly a terrible solution. We need structural changes, like:
* Namespaces on crates.io (I believe people are working on this).
* Crate level effects systems ("zlib shouldn't be able to access environment variables, the filesystem or network"). No idea if anyone is working on that or if it is already possible. CHERI provides one solution which people definitely are working on.
* Probably a bigger standard library, or at least a set of crates that are maintained by core Rust developers. I vaguely recall that this might happen.
Anyway the sensible among as aren't demanding this work. We're just saying it would be really good if it happened.
Whereas this misguided person is saying "nothing more is needed" which shows a lack of understanding and imagination.
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.