5 ms·

No one owes you supply-chain security

75 points by birdculture 7mo ago

huflungdung 7mo ago
[dead]
MeetingsBrowser 7mo 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.
- trollbridge 7mo 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.
  - MeetingsBrowser 7mo 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.
    - 6keZbCECT2uB 7mo ago
      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.
      - skeeter2020 7mo ago
        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.
        cuu508 7mo ago
        Does this really happen? Can you provide concrete examples?
        well_ackshually 7mo ago
        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.
        ahtihn 7mo ago
        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?
        7mo ago
  - skeeter2020 7mo 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.
    - worthless-trash 7mo ago
      I applaude your dedication to the bit.
  - 4bpp 7mo 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".
  - staticassertion 7mo 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 7mo 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?
- Jerrrrrrrry 7mo ago
  [dead]
- deleted 7mo ago
  [deleted]
- zdw 7mo 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 7mo ago
    One could have different tiers of repository for different levels of trust. In arch Linux, I trust the base repositories more than AUR.
  - hnlmorg 7mo 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 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.
  - jjav 7mo 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 7mo 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.
  - hnlmorg 7mo 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.
    - ForHackernews 7mo ago
      No one has an ethical responsibility to provide free security auditing to trillion dollar companies.
      - hnlmorg 7mo ago
        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.
- mightyham 7mo 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.
- pabs3 7mo ago
  > We are owed supply chain security. Careful, requiring that might get you completely unmaintained software instead.
Zigurd 7mo 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 7mo 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.
- general1465 7mo 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 7mo 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?
    - general1465 7mo ago
      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.
      - pixl97 7mo ago
        Ok, so free software cannot exist is what you're telling us. Hell, I swear Microsoft and Oracle has their lawyers in here posting.
        general1465 7mo ago
        I am just saying that license, TOS or lack of both is not above the law.
        7mo ago
Pesthuf 7mo 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_ 7mo 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 7mo 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…
    - junon 7mo ago
      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.
  - lelanthran 7mo 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 7mo 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 https://go.dev/ref/mod#checksum-database
jruohonen 7mo 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 https://news.ycombinator.com/item?id=47585172
torginus 7mo 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.
IshKebab 7mo 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.
- deleted 7mo ago
  [deleted]
- ahtihn 7mo 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.
  - IshKebab 7mo 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.
    - pixl97 7mo ago
      > 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.
      - IshKebab 7mo ago
        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.
torginus 7mo 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.
- junon 7mo 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.
  - torginus 7mo 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.
    - pabs3 7mo ago
      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/ https://reproducible-builds.org/ And it should be possible to build the entire system from scratch without trusting any binaries. https://bootstrappable.org/ https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://lwn.net/Articles/983340/ https://stagex.tools/ https://stagex.tools/
    - junon 7mo ago
      Which build server? Not everyone has the luxury, and that also means you have to secure a build server now too. For rust, there is no build server. Packages are distributed as code.
staticassertion 7mo 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 7mo 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.
- junon 7mo 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."
  - lelanthran 7mo 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".

75 points by birdculture 7mo ago

[dead]

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

trollbridge 7mo 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.
- MeetingsBrowser 7mo 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.
  - 6keZbCECT2uB 7mo ago
    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.
    - skeeter2020 7mo ago
      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.
      - cuu508 7mo ago
        Does this really happen? Can you provide concrete examples?
      - well_ackshually 7mo ago
        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.
      - ahtihn 7mo ago
        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?
      - 7mo ago
- skeeter2020 7mo 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.
  - worthless-trash 7mo ago
    I applaude your dedication to the bit.
- 4bpp 7mo 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".
- staticassertion 7mo 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 7mo 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?
Jerrrrrrrry 7mo ago
[dead]
deleted 7mo ago
[deleted]
zdw 7mo 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 7mo ago
  One could have different tiers of repository for different levels of trust. In arch Linux, I trust the base repositories more than AUR.
- hnlmorg 7mo 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 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.
- jjav 7mo 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 7mo 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.
- hnlmorg 7mo 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.
  - ForHackernews 7mo ago
    No one has an ethical responsibility to provide free security auditing to trillion dollar companies.
    - hnlmorg 7mo ago
      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.
mightyham 7mo 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.
pabs3 7mo ago
> We are owed supply chain security. Careful, requiring that might get you completely unmaintained software instead.

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

general1465 7mo 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 7mo 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?
  - general1465 7mo ago
    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.
    - pixl97 7mo ago
      Ok, so free software cannot exist is what you're telling us. Hell, I swear Microsoft and Oracle has their lawyers in here posting.
      - general1465 7mo ago
        I am just saying that license, TOS or lack of both is not above the law.
        7mo ago

Pesthuf 7mo 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_ 7mo 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 7mo 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…
  - junon 7mo ago
    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.
- lelanthran 7mo 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 7mo 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 https://go.dev/ref/mod#checksum-database

jruohonen 7mo 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 https://news.ycombinator.com/item?id=47585172

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

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

deleted 7mo ago
[deleted]
ahtihn 7mo 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.
- IshKebab 7mo 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.
  - pixl97 7mo ago
    > 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.
    - IshKebab 7mo ago
      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.

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

junon 7mo 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.
- torginus 7mo 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.
  - pabs3 7mo ago
    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/ https://reproducible-builds.org/ And it should be possible to build the entire system from scratch without trusting any binaries. https://bootstrappable.org/ https://bootstrappable.org/ https://lwn.net/Articles/983340/ https://lwn.net/Articles/983340/ https://stagex.tools/ https://stagex.tools/
  - junon 7mo ago
    Which build server? Not everyone has the luxury, and that also means you have to secure a build server now too. For rust, there is no build server. Packages are distributed as code.

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

junon 7mo 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."
- lelanthran 7mo 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".