331–340 of 509 posts
I see a way to solve this with technology and that is for tools to allow secondary developers to publish on the package repository, but after a mandatory N-day delay. The main owner can then always have a chance to review.
And then attackers would just wait that N days before pushing exploits.
Earlier quoted context omitted.
Especially given that Dominic maintains hundreds of packages[1]. He's a good guy and a great developer, and he's always been supportive of others who want to help out. When working on Scuttlebutt[2] I got some flak for a change I made and he said this[3]: > I argued against this before, but @christianbundy wanted to do it, so I figured okay do it then. Maybe it is annoying for everyone (in which case christian probab…
> Especially given that Dominic maintains hundreds of packages > maintains hundreds of packages > hundreds How can a single human reasonably and responsably do this? This number alone demonstrates how sloppy and inept the Node.js community's practices are.
Earlier quoted context omitted.
No, there is no alternative. You are responsible for what you ship. Even if you pay for the software, you should vet it as best you can as you're responsible.
How are you going to have the time and skill to vet Oracle anything?
Monitor the network, make sure you know where the data is going. Things like that.
Earlier quoted context omitted.
Handing over a popular software project to a random stranger you've never spoken to who asks to take it over is just irresponsible. Nothing is preventing that stranger from adding malicious code and potentially compromising millions of devices, which is exactly what happened.
Explain how you would be able to evaluate the trustworthiness of a person asking to transfer ownership to.
1. - don't transfer - mark your repo Abandoned, tell people to use that other person's fork if you have to 2. - does that person have any other online presence? Long running? 3. - does he also put his face in front of the crowd? Talk at conferences?
This creates accountability - someone like that wouldn't pull out the same kind of injection, because he could be caught for that and his "brand" would be destroyed.
Earlier quoted context omitted.
No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.
A reasonable position -- and obviously better in this case -- but in general I'm not sure most people agree. The overwhelming majority of the time maintainers are not malicious.
Unpinned dependencies are harmful. If you aren’t reviewing the diffs of your dependencies when you update them, you’re trusting random strangers on the Internet to run code on your systems. Espionage often spans multi-year timelines of preparation and trust building. No lesser solution will ever be sufficient to protect you. Either read the diffs, or pay someone like RedHat to do so and hope that you can trust them.
Earlier quoted context omitted.
No. Transferring a project wholesale to an unknown maintainer is effectively a fork; I'd much rather have my dependencies die than start silently pulling in a fork. If I want to swap in right9ctrl/event-stream, I'll do it myself.
> I'd much rather have my dependencies die than start silently pulling in a fork. Maybe, but Node had that issue too, no? Remember leftpad? So, lots of people in the Node ecosystem don't agree with you.
Earlier quoted context omitted.
This must be the fifth incident that could have been readily prevented if npm simply required signing for it's packages. Just do the same thing we have for SSH: on first connection (installation), ask if you trust the other side. That goes into your authorized_keys (lock file). If you connect again (update) and the key changed, print a big scary warning. No blockchain needed.
This was, from the eyes of npm Inc. and everyone else a completely legitimate ownership transfer. There was a "human error" (Domenic trusting the wrong person) that was completely unpreventable by technological means. There was no hijacking involved.
Earlier quoted context omitted.
Lots of tiny dependencies.
Exactly. As a Java dev, I can't imagine creating a dependency for such a tiny thing. I would want a reputable library. My dependency tree can grow pretty big but not nearly as much as my typical node_modules.
For instance, if I was going to do something similar to left-pad in a .NET way, I'd have to create a whole Visual Studio project and build a DLL for a single function, which would rightly be recognized as pants-on-head.