←back to thread

1208 points jamesberthoty | 1 comments | | HN request time: 0.198s | source
Show context
kelnos ◴[] No.45266878[source]
As a user of npm-hosted packages in my own projects, I'm not really sure what to do to protect myself. It's not feasible for me to audit every single one of my dependencies, and every one of my dependencies' dependencies, and so on. Even if I had the time to do that, I'm not a typescript/javascript expert, and I'm certain there are a lot of obfuscated things that an attacker could do that I wouldn't realize was embedded malware.

One thing I was thinking of was sort of a "delayed" mode to updating my own dependencies. The idea is that when I want to update my dependencies, instead of updating to the absolute latest version available of everything, it updates to versions that were released no more than some configurable amount of time ago. As a maintainer, I could decide that a package that's been out in the wild for at least 6 weeks is less likely to have unnoticed malware in it than one that was released just yesterday.

Obviously this is not a perfect fix, as there's no guarantee that the delay time I specify is enough for any particular package. And I'd want the tool to present me with options sometimes: e.g. if my current version of a dep has a vulnerability, and the fix for it came out a few days ago, I might choose to update to it (better eliminate the known vulnerability than refuse to update for fear of an unknown one) rather than wait until it's older than my threshold.

replies(35): >>45266995 #>>45267024 #>>45267360 #>>45267489 #>>45267600 #>>45267697 #>>45267722 #>>45267967 #>>45268218 #>>45268503 #>>45268654 #>>45268764 #>>45269143 #>>45269397 #>>45269398 #>>45269524 #>>45269799 #>>45269945 #>>45270082 #>>45270083 #>>45270420 #>>45270708 #>>45270917 #>>45270938 #>>45272063 #>>45272548 #>>45273074 #>>45273291 #>>45273321 #>>45273387 #>>45273513 #>>45273935 #>>45274324 #>>45275452 #>>45277692 #
eschneider ◴[] No.45267360[source]
If you pull something into your project, you're responsible for it working. Full stop. There are a lot of ways to manage/control dependencies. Pick something that works best for you, but be aware, due diligence, like maintenance is ultimately your responsibility.
replies(3): >>45267390 #>>45267968 #>>45268507 #
IshKebab ◴[] No.45267390[source]
That's very naive. We can do better than this.
replies(1): >>45267550 #
hermannj314 ◴[] No.45267550[source]
Almost all software has a no warranty clause. I am not a lawyer but in pretty plain English every piece of software I have ever used has said exactly that I can fuck off if I expect it to work or do anything.

To clarify - I dont think it is naive to assume the software is as-is with all responsibilities on the user since that is exactly what lawyers have made all software companies say that for over 50 years.

replies(2): >>45268051 #>>45268321 #
gmueckl ◴[] No.45268051[source]
Product liability is coming for software. Warranty disclaimers in licenses will be rendered ineffective by the end of 2026 at the latest.
replies(3): >>45268937 #>>45269110 #>>45269226 #
tcoff91 ◴[] No.45268937[source]
Source? An open source library is not necessarily a ‘product’ at all.
replies(1): >>45269240 #
1. LtWorf ◴[] No.45269240[source]
No source because it's not real. There's talk about final products and making the companies selling them responsible. But open source developers are not responsible.