▲ | dabockster 4 days ago | |||||||||||||||||||||||||||||||
That wouldn't work against a really sophisticated attacker. Especially for something that's clearly being maintained for free by one overworked person in their spare time (yet again). You'd need some kind of offline verification method as well for these widely used infrastructure libraries. | ||||||||||||||||||||||||||||||||
▲ | lelanthran 3 days ago | parent [-] | |||||||||||||||||||||||||||||||
> That wouldn't work against a really sophisticated attacker. Nothing "really works" against a sophisticated hacker :-/ Doesn't mean that "defense in depth" does not apply. > You'd need some kind of offline verification method as well for these widely used infrastructure libraries. I don't understand why this is an issue, or even what it means: uploading a new package to the repository requires the contributor to be online anyway. The new/updated/replacement package will have to be signed. The signature must be verified by the upload script/handler. The verification can be done using the X509 certificate issued for the domain of the contributor. 1. If the contributor cannot afford the few dollars a year for a domain, they are extremely vulnerable to the supply chain attack anyway (by selling the maintenance of the package to a bad actor), and you shouldn't trust them anyway. 2. If the contributor's domain gets compromised you only have to revoke that specific certificate, and all packages signed with that certificate, in the past or in the future, would not be installable. As I have repeatedly said in the past, NPM (and the JS tools development community in general) had no adults in the room during the design phase. Everything about JS stacks feels like it was designed by children who had never programmed in anything else before. It's a total clown show. | ||||||||||||||||||||||||||||||||
|