No one owes you supply-chain security
purplesyringa.moe
purplesyringa.moe
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.
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.
The software is provided as is.
Blindly pulling updates from providers that offer you no contractual guarantees has to be gross negligence right?
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?
Let's take npm. The postinstall scripts and auto fetching of dependencies have always been seen as problematic. So plenty of warnings beforehand, but people chose convenience over security.
Debian's package management has the same feature (postinstall scripts and dependencies management). But the risks are lower, mostly because your main targets would be a core group of committers, which I'd like to believe is more conscious about security risks. And there's a lot of reviews before binaries are built and made available in a stable version. And I'd also like believe popular packages like nginx, curl, coreutils, postgresql,... have a lot more eyeballs on them.
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.
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.
Take it to the extreme. What if I write a library, put an OSS license on it, advertise it, and then bundle malware in the release.
Am I fault for including malicious code, or are the users who downloaded it entitled for expecting the code, that I asked them to use, will not harm them.
I would argue the burden is mostly on the user for smaller niche projects, but mostly on the developer for large, heavily advertised, critical infrastructure projects.
It is not entitlement to expect operating systems, package managers, browsers, etc to be following good practices.
It is the definition of entitlement, because what you are claiming is "good practices" is actually "ongoing labor and active management."
And, again, contravenes the license you agreed to. If you don't like that, you should execute a contract that does offer the support you want.
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.
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".
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?
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.
In arch Linux, I trust the base repositories more than AUR.
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.
Yes you can, companies just don't like the answer.
To run with that analogy, if you are setting up that taxi company, will you build your fleet by picking up free gokarts around the neighborhood, or by purchasing cars from a known manufacturer who has gone through crash testing etc?
Not particularly different for software. If you need certified quality, you need to pay the providers fairly substantial amounts of money for that.
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.
Developers have an ethical responsibility but that doesn’t mean they should be legally accountable for genuine mistakes.
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.
Anyone who is not paying me can use what I generously give away for free without THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Concerned about security? Good for you, build it yourself.
And who isn't honest about it? Read the contract you have with the provider.
There is a way to legitimately expect production-ready libraries: You sign a purchase order for the right to use that code for a year (typically, or multi-year) and pay a quite substantial amount of money for that. Then you have purchased the right to expect a certain level of quality (details can be in the contract and reflected in the price).
If you're using something for free without having agreed to such a contract and paid the vendor accordingly, then you can expect exactly as much as you paid for it.
If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”
The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases.
I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.
No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code.
Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is.
It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it.
All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is.
All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.
Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document.
So when it says something like (this from MIT license):
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.
That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use.
If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it.
Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.
And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source.
If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup.
I say all of this as an open source maintainer. Just be honest in your READMEs.
A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source.
Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena.
Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.
The license (most, anyway) clearly state the software is not necessarily suitable for any purpose and that's all you get.
If you require a higher level of confidence than none, then you should be paying for a support contract.
All I can say without being repetitive is that if you expect more than nothing when the license specifically says all you can expect is nothing, you might be disappointed more often than not.
And why you describe absolutely is not how any of more reputable libraries nor maintainers approach open source software.
So you might feel like you are legally correct. But you’re still completely missing the point.
I published my first open source (we didn't call it that) program in the 1980s.
I didn't know anything about licenses back then (and the open source licenses we use today didn't yet exist), so I just put a header comment on it saying something along the lines of "This code is public domain, feel free to try it but I can't guarantee it'll work for you." (although I can't remember exact wording). This is how it's always been.
> But you’re still completely missing the point.
I suggest considering the fact that you're disappointed that open source libraries aren't providing the guarantees you feel they owe you (which they don't) is an indicator that perhaps your expectations are not in line with what open source is all about.
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.
I think you’re being overly simplistic with your position because there is a sane middle ground where maintainers are honest about their projects (eg so often pet projects have readme’s that describe POC code as if it’s production ready, and that’s not ok)
I’m not suggesting that users of open source packages don’t also have responsibility to vet the packages they import. But so often I’ve wasted time vetting a package that has made bold claims in the README only to discover it’s basically beta software. And that can be hours of my free time wasted just because the author wanted their CV to sound more impressive.
On my open source projects, I very clearly list when things are going to be beta quality, where experimental code lives, and where stuff is tested and considered safe for production use. I do that because I value people’s time. Just like I value my own time. And it only takes me 2 minutes to add that detail to the readme.
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.
Careful, requiring that might get you completely unmaintained software instead.
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?
Don’t get me started on everyone being git@github.com…
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.
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.
https://reproducible-builds.org/
And it should be possible to build the entire system from scratch without trusting any binaries.
https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://stagex.tools/
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
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".
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.
Let's recall the classic analogy of rms: "Free as in Beer" and "Free as in Speech".
"Free Software" and its cousins, F/OSS, and Creative Commons, are "Free as in Speech" (in Spanish: libre).
This freedom often means it is provided free of charge. But it does not require it. Free software may cost money. In fact, we now often pay for free software, because it's incorporated in our routers, our smartphones, our smart home devices, our IoT things. SaaS is replete with free software under the hood, yet we pay for subscriptions and access and all kinds of costly things that incur fees. Free software is ubiquitous and often costs $$$ just to distribute it. Ask anyone who subscribes to Red Hat Enterprise Linux.
Please stop with your stupid analogies comparing a "free car" to Free Software. They aren't the same thing by any means. If I serve you "Free Beer" all night, and you don't get drunk, that has nothing to do with Free Software or Free Speech: capice?
Do you know what you pay for when you pay Red Hat? Exactly the kind of guarantees people seem to expect from free software. You're not paying for the software, you're paying for the contractual support relationship. If you're updating your RHEL server through the channels you are paying for, you'd absolutely be able to sue Red Hat if they were distributing compromised software.
The cost matters. No one's taking on legal liability free of charge.
You can't expect any guarantees of fitness for purpose, safety or whatever if you're getting something for free. The moment you pay though, things change and licenses can't absolve you from everything.
The people who are confused are claiming that "Free Software" is zero-cost, and you yourself contradict that belief. "Free Software" is not "free as in beer".
However, just because software is provided free of cost, doesn't mean it can't be supported, or the developers held liable. I don't see really what kind of difference that would make. I mean, other than creating an actual and direct contractual agreement between customer and distributor. If you grab a download for no money, that's obviously different than paying for a subscription, and signing a contract that includes an SLA.
But that doesn't preclude "Free as in Beer" software from having guarantees. Why should it?
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.