Hacker News new | ask | show | jobs
by 6keZbCECT2uB 72 days 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.

2 comments

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

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?

Does this really happen? Can you provide concrete examples?
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.
If I will poison you (for free of course) am I absolved of guilt because I did not want a payment for that?
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.

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.