> 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.
For one, there is a limit to how much licenses absolve you from responsibility — like, you can’t say “eat my food, by doing so you accept responsibility” and turns out it’s poisoned. It’s still possible to go after the food producer.
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.
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.
As an open source maintainer myself, I don’t think it’s an insulting position at all.
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.
> 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 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.
You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project.
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.
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.
It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise.
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.
It really isn’t much to ask people not to bullshit in their own README. That’s literally all I’m asking for. If you don’t want to offer software guarantees then don’t write your README like you offer it. It’s really that simple.
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.
I'm not suggesting honesty should be behind a paywayll. Honesty should be upfront and it already is, in the license.
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.
Anyone who is making money off my open source work can PAY ME if they want signed, reproducible builds.
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.
You’re missing the point again, but let’s just agree to disagree because it sounds like your more concerned about money than the topic being discussed. Which is fine. It’s an opinion. I just don’t agree that it’s relevant
> 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.
> 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.
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.
You would note that known manufacturers only sell non-repairable insecure spyware on wheels and instead pick up the libre gokart designs the groups of neighborhood kids made, build a few of them, try them out, figure out all the safety/repairability/design flaws, fix those, publish your fixes (either back to the kids or in forks), hire some of the kids, start selling services, share some of your profits to the kids whose designs you chose, and otherwise help the community around the original designs etc.
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.
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.
I think people are scratching at a cognitive dissonance around:
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?
Your reasonable options are:
1. I stop sharing the software I write
2. You take responsibility for the software you use
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.
that clause - even in all caps - doesn't absolve them like you think it does. A quick example: if credentials were comprimised and malware pushed and it was determined to be due to reasonably preventible negligence an author could be held responsible.
No, they wouldn't be "held responsible". There is a great deal of insecure code out there and I have yet to see some open-source author found liable for that.
No. Because the only reason you then get hit by this new version with malware is either that you're not pinning your versions (and that's irresponsible), or you're blindly bumping (and that's irresponsible.)
Your analogy breaks down outside of an industrial food safety QA'd supply chain. What you're calling "poisoning" is what in industrial Food Safety is known as "introduction of an adulteration", where an "adulteration" is defined as an undesired addition of an ingredient to a food producer's standard recipe.
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.
Poisoning is intent. If I leaves a cup of some liquid with a clear warning that it has not be tested for being drinkable, I don’t think that I’m liable for you being poisoned when you go and drink it. Especially if I do not sell drinks. Of course, there are regulations about safety, but they are mostly about when you’re at risk of being harmed while I use my tools for myself. They’re not about you ignoring warnings labels and getting harmed.
No one is selling anything. A lot of OSS projects don't even distribute binaries, only code tarballs. If the risks are substantial enough for you to worry about, you take the source code and review them. Then you run it if it's satisfactory.
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.
Sorry, but that's really absurd entitlement and also contravenes the license.
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.
Gifts come with some implied responsibility from the giver and a niche hobby project is different from a package manager.
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.
The problem here is that there is more than two metaphorical people involved: there is the developer, the would-be user, and the evangelist who harangues the developer with "rewrite it in Rust brah" drive-by comments or blog posts about how nobody sane would use memory-unsafe languages/ecosystems without a vibrant community package management ecosystem in the year of our lord 2026.
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".
I think that they arguably do when they publish to a registry. I think that crosses a bridge from "I'm just writing software" and "I'm publishing software for consumption". Arguably, to be clear, I don't have very strong feelings, but I think there is a distinction between "I've placed code online" and "I've explicitly published it for use".
>> Free software developers don't have any obligations to anyone else.
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.
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.
Giving people food for free (without written contract) but poising them in the process will leave you in hot water with authorities. Why software should be different?
Trying to answer what I think is the most reasonable point you’re trying to make: supply chain extends beyond you and your actions.
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?
If you will get bad food, who are you going to blame? Very likely the person who you get the food from, not going up the supply chain like a detective.
Well actually you ate poisoned food made by someone else, which had a similar looking name (typo squatting).
Who is responsible here? One who wrote code?
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?
Multiple package managers are trying to move to ssh keys and other stronger forms of verification, as well as trying to outlaw binary tarballs and other such things. It's somewhat slow going: package owners sometimes get grouchy about this and drag their feet.
Which is wild we’re coming full circle. Everyone made these things easy to publish to so we could onboard newbies faster but then we all figured out that sacrificing security to save someone 10 minutes of reading was a bad idea.
Don’t get me started on everyone being git@github.com…
Not quite the history as I remember it. These package managers were often created by small teams of people who originally didn't know they'd turn into Microsoft acquired corporations. The intent wasn't to onboard newbies. People just didn't have a reason to use insanely targeted attacks on OSS Things because OSS being used in such a widespread manner wasn't as common as it is today. It really feels like people have forgotten how things were back then.
> Multiple package managers are trying to move to ssh keys and other stronger forms of verification, as well as trying to outlaw binary tarballs and other such things.
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.
> 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, by build script I mean the script that generates the package, not the actual build. That should run on the build server, not the developer's machine.
I think it would be better if the build process ran on both the build server and the devs machine and get the exact same output on both with deterministic/reproducible build processes.
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.
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.
This is very "old man yells at cloud" reductionist commentary IMO. You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
> You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
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".
> 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
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.
"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.
It's clear that people in this thread do not understand what "Free Software" is, and what it isn't.
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.
Yeah, obviously, Free Software vendors can support themselves in certain ways, chiefly being the selling of support contracts.
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?
Poor analogy. Nobody is saying that there is a legal obligation for the Rust community to improve supply chain security, but this post is saying it's already fine; we don't need to improve things - just do your own auditing! which is the kind of "just don't make mistakes" bullshit that led people to create Rust in the first place.
Nobody is being entitled or demanding that others do work. We just also aren't saying "it's fine; there's no problem".
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.
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.
> 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.
For one, there is a limit to how much licenses absolve you from responsibility — like, you can’t say “eat my food, by doing so you accept responsibility” and turns out it’s poisoned. It’s still possible to go after the food producer.
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.
Didn’t Disney famously use an EULA contract for dodging responsibility after a deadly food poisoning?
That’s a slightly different thing in my opinion but I’m glad that you’ve raised it.
Developers have an ethical responsibility but that doesn’t mean they should be legally accountable for genuine mistakes.
This is rather insulting.
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.
As an open source maintainer myself, I don’t think it’s an insulting position at all.
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.
No one has an ethical responsibility to provide free security auditing to trillion dollar companies.
That’s a strawman argument because we aren’t talking about security auditing for trillion dollar companies.
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.
> 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 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.
You’re twisting my argument. I’m not saying maintainers are obligated to make their code production ready. I said their READMEs should accurately represent the state of the project.
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”
> I said their READMEs should accurately represent the state of the project.
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.
> The state of expectations is usually in the LICENSE file, not in the README.
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.
It is interesting how every time this topic comes up it ends up with people for the most part in one of two camps: either the license is meant to be taken literally, or those who believe otherwise.
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.
It really isn’t much to ask people not to bullshit in their own README. That’s literally all I’m asking for. If you don’t want to offer software guarantees then don’t write your README like you offer it. It’s really that simple.
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.
I'm not suggesting honesty should be behind a paywayll. Honesty should be upfront and it already is, in the license.
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.
Anyone who is making money off my open source work can PAY ME if they want signed, reproducible builds.
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.
You’re missing the point again, but let’s just agree to disagree because it sounds like your more concerned about money than the topic being discussed. Which is fine. It’s an opinion. I just don’t agree that it’s relevant
> 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.
> 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.
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.
You would note that known manufacturers only sell non-repairable insecure spyware on wheels and instead pick up the libre gokart designs the groups of neighborhood kids made, build a few of them, try them out, figure out all the safety/repairability/design flaws, fix those, publish your fixes (either back to the kids or in forks), hire some of the kids, start selling services, share some of your profits to the kids whose designs you chose, and otherwise help the community around the original designs etc.
Important security packages should be audited by 3rd party researchers and their results shared. For example https://github.com/RustCrypto/RSA?tab=readme-ov-file
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.
One could have different tiers of repository for different levels of trust.
In arch Linux, I trust the base repositories more than AUR.
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.
I think people are scratching at a cognitive dissonance around:
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?
Once you advertise and ask people use your software in production, you have an obligation to make sure it is somewhat safe.
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.
Your reasonable options are: 1. I stop sharing the software I write 2. You take responsibility for the software you use
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.
that clause - even in all caps - doesn't absolve them like you think it does. A quick example: if credentials were comprimised and malware pushed and it was determined to be due to reasonably preventible negligence an author could be held responsible.
Are companies that are compromised by supply chain attacks held responsible for their negligent behavior?
Blindly pulling updates from providers that offer you no contractual guarantees has to be gross negligence right?
No, they wouldn't be "held responsible". There is a great deal of insecure code out there and I have yet to see some open-source author found liable for that.
No. Because the only reason you then get hit by this new version with malware is either that you're not pinning your versions (and that's irresponsible), or you're blindly bumping (and that's irresponsible.)
The software is provided as is.
Does this really happen? Can you provide concrete examples?
If I will poison you (for free of course) am I absolved of guilt because I did not want a payment for that?
Your analogy breaks down outside of an industrial food safety QA'd supply chain. What you're calling "poisoning" is what in industrial Food Safety is known as "introduction of an adulteration", where an "adulteration" is defined as an undesired addition of an ingredient to a food producer's standard recipe.
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.
Poisoning is intent. If I leaves a cup of some liquid with a clear warning that it has not be tested for being drinkable, I don’t think that I’m liable for you being poisoned when you go and drink it. Especially if I do not sell drinks. Of course, there are regulations about safety, but they are mostly about when you’re at risk of being harmed while I use my tools for myself. They’re not about you ignoring warnings labels and getting harmed.
IANAL.
You can get poisoned unintentionally, as it happens in supply chain attacks.
A supply chain attack would be intentional, just not intentional by the creator.
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?
You screw up by poisoning me. However if I will sell that drink to somebody else then I will be on the hook for poisoning them.
No one is selling anything. A lot of OSS projects don't even distribute binaries, only code tarballs. If the risks are substantial enough for you to worry about, you take the source code and review them. Then you run it if it's satisfactory.
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.
You don't need to sell it, you can give it on the corner of the street, same problem.
Sorry, but that's really absurd entitlement and also contravenes the license.
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.
Gifts come with some implied responsibility from the giver and a niche hobby project is different from a package manager.
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 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.
The problem here is that there is more than two metaphorical people involved: there is the developer, the would-be user, and the evangelist who harangues the developer with "rewrite it in Rust brah" drive-by comments or blog posts about how nobody sane would use memory-unsafe languages/ecosystems without a vibrant community package management ecosystem in the year of our lord 2026.
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".
I think that they arguably do when they publish to a registry. I think that crosses a bridge from "I'm just writing software" and "I'm publishing software for consumption". Arguably, to be clear, I don't have very strong feelings, but I think there is a distinction between "I've placed code online" and "I've explicitly published it for use".
>> Free software developers don't have any obligations to anyone else.
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.
I applaude your dedication to the bit.
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.
> We are owed supply chain security.
Careful, requiring that might get you completely unmaintained software instead.
[dead]
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.
Giving people food for free (without written contract) but poising them in the process will leave you in hot water with authorities. Why software should be different?
Trying to answer what I think is the most reasonable point you’re trying to make: supply chain extends beyond you and your actions.
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?
If you will get bad food, who are you going to blame? Very likely the person who you get the food from, not going up the supply chain like a detective.
Well actually you ate poisoned food made by someone else, which had a similar looking name (typo squatting). Who is responsible here? One who wrote code?
It was not me sir who poisoned you, it was Josh, my evil twin! I swear!
Ok, so free software cannot exist is what you're telling us. Hell, I swear Microsoft and Oracle has their lawyers in here posting.
I am just saying that license, TOS or lack of both is not above the law.
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?
Multiple package managers are trying to move to ssh keys and other stronger forms of verification, as well as trying to outlaw binary tarballs and other such things. It's somewhat slow going: package owners sometimes get grouchy about this and drag their feet.
Which is wild we’re coming full circle. Everyone made these things easy to publish to so we could onboard newbies faster but then we all figured out that sacrificing security to save someone 10 minutes of reading was a bad idea.
Don’t get me started on everyone being git@github.com…
Not quite the history as I remember it. These package managers were often created by small teams of people who originally didn't know they'd turn into Microsoft acquired corporations. The intent wasn't to onboard newbies. People just didn't have a reason to use insanely targeted attacks on OSS Things because OSS being used in such a widespread manner wasn't as common as it is today. It really feels like people have forgotten how things were back then.
> Multiple package managers are trying to move to ssh keys and other stronger forms of verification, as well as trying to outlaw binary tarballs and other such things.
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.
> 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.
Build scripts often look for system libraries, generate larger artifacts, etc. It's not as black and white as you make it out to be.
Sorry, by build script I mean the script that generates the package, not the actual build. That should run on the build server, not the developer's machine.
I think it would be better if the build process ran on both the build server and the devs machine and get the exact same output on both with deterministic/reproducible build processes.
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/
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.
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.
This is very "old man yells at cloud" reductionist commentary IMO. You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
> You're conflating two things, shrouded by your pre-existing distaste for the comments a few people have made. This article is not a critique of the language but of the tooling around it. You're conflating memory safety and supply chain safety, as if to say "people told me to drive cars because they gave seatbelts, but puh, Gas still explodes. I'll take a horse, thanks."
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".
> 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
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.
https://go.dev/ref/mod#checksum-database
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.
[dead]
"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.
The analogy is more like
"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.
It's clear that people in this thread do not understand what "Free Software" is, and what it isn't.
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?
You're confused.
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.
Yeah, obviously, Free Software vendors can support themselves in certain ways, chiefly being the selling of support contracts.
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?
give me free robux
Poor analogy. Nobody is saying that there is a legal obligation for the Rust community to improve supply chain security, but this post is saying it's already fine; we don't need to improve things - just do your own auditing! which is the kind of "just don't make mistakes" bullshit that led people to create Rust in the first place.
> just do your own auditing!
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.
Nobody is being entitled or demanding that others do work. We just also aren't saying "it's fine; there's no problem".
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.
hello retard
[dead]
[dead]
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.