No one owes you supply-chain security

https://purplesyringa.moe/blog/no-one-owes-you-supply-chain-security/

by birdculture • 3 months ago

75 88 3 months ago

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.

trollbridge2• 3 months ago

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.

MeetingsBrowser3• 3 months ago

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.

skeeter20202• 3 months ago

> 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.

4bpp• 3 months ago

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".

staticassertion2• 3 months ago

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".

saltcured• 3 months ago

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?

zdw• 3 months ago

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.

unethical_ban• 3 months ago

One could have different tiers of repository for different levels of trust.

In arch Linux, I trust the base repositories more than AUR.

hnlmorg9• 3 months ago

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.

jjav6• 3 months ago

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.

marssaxman• 3 months ago

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.

hnlmorg9• 3 months ago

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.

anon7000• 3 months ago

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.

mightyham• 3 months ago

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.

pabs33• 3 months ago

We are owed supply chain security.

Careful, requiring that might get you completely unmaintained software instead.

Zigurd• 3 months ago

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.

1970-01-01• 3 months ago

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.

general14658• 3 months ago

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?

awakeasleep• 3 months ago

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?

Pesthuf• 3 months ago

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?

Analemma_• 3 months ago

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.

cr125rider• 3 months ago

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…

lelanthran2• 3 months ago

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.

skybrian• 3 months ago

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

jruohonen• 3 months ago

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

torginus3• 3 months ago

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.

IshKebab3• 3 months ago

"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.

ahtihn3• 3 months ago

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.

IshKebab3• 3 months ago

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.

ButlerianJihad2• 3 months ago

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?

gayboy2• 3 months ago

hello retard

torginus3• 3 months ago

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.

junon4• 3 months ago

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.

torginus3• 3 months ago

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.

staticassertion2• 3 months ago

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.

cheney_2004• 3 months ago

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.

junon4• 3 months ago

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."

lelanthran2• 3 months ago

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".

No one owes you supply-chain security

Related Stories