If they wanted him to have the responsibility of doing due diligence, companies depending on his library should have paid him. He stated that he was doing it for fun and it stopped being fun so he handed it off to someone else as quickly as they showed up. It was a hobby project.
Conversation
Or they should have done the due diligence themselves. Blindly upgrading to a new version of the library from a different maintainer was their choice. How were they even verifying the sources? Doesn't sound like anything was signed, and an account takeover could have done this.
2
So apparently npm has no package signing. I didn't realize it was that bad. The previous developer didn't even need to hand over a signing key to the new developer, since nothing is being signed and verified anyway. What if they had simply chosen a bad / reused password for npm?
1
1
hard to imagine how package signing works without key management, and key management doesn’t work at scale, so i’m not sure this is a super fair criticism
1
1
2
I think TUF works well for managing a developer PKI and applying package AuthZ policies, however it’s also worth noting that would’ve done nothing to prevent this particular attack, since it was malware injected via transitive dependencies by an authorized publisher
1
There are language package managers with package signing. At the very least, pinning the key fingerprint on first use with a mechanism for automatically rotating to requiring signatures from additional new keys works well.
2
1
I'm not sure that end-user key management actually does work well for a system that operates at the scale that NPM does. Do you know what the largest deployment of such a package manager is?
2
I don't understand what scale has to do with it. Package signing works fine for many other package managers with a large scale. The basic trust on first use security properties don't require any end user key management or extra work on their part.
1
This Tweet was deleted by the Tweet author. Learn more
I too have direct experience working on many package managers specifically on the problem of package signing, and I would argue for a signing system to be useful, at a minimum every package needs to be signed by a key which is ultimately trusted by the end user
2
I don't know exactly what you're saying. I think it's very extreme and clearly wrong to claim that automatic trust-on-first-use isn't useful, and getting the initial system in place makes it possible to do better. I don't buy excuses for not even providing package signing at all.
Quote Tweet
Replying to @bascule @DanielMicay and @hdevalence
...but then there’s this problem to consider: how to handle key rotation tonyarcieri.com/key-rotation-u
1
I already mentioned that earlier:
twitter.com/DanielMicay/st
It fits fine into an automatic trust-on-first-use system as the baseline package signing implementation. Doing more on top of that baseline is enabled by having the basic package signing in place.
Quote Tweet
Replying to @bascule and @hdevalence
There are language package managers with package signing. At the very least, pinning the key fingerprint on first use with a mechanism for automatically rotating to requiring signatures from additional new keys works well.
1
Show replies