4 ms·

Good luck explaining this https://news.ycombinator.com/item?id=16087079 https://news.ycombinator.com/item?id=16087079 in the face of this https://news.ycombi

by danjoc 9y ago

Good luck explaining this https://news.ycombinator.com/item?id=16087079 https://news.ycombinator.com/item?id=16087079 in the face of this https://news.ycombinator.com/item?id=14905870 https://news.ycombinator.com/item?id=14905870 Literally nothing was done for 158 days. You yourself asked: https://github.com/node-forward/discussions/issues/29#issuecomment-320170082 https://github.com/node-forward/discussions/issues/29#issuec... "How would package signing prevent people from requesting the wrong package? The malware author could also sign their package." And here is a perfect example. Someone replaced a legit package with a malicious one. Had the original author signed the package, then then NPM users could have defended against the new malicious author, because the new author's signing key would not be in their truststore. Unsigned packages leave NPM package users defenseless. I hope that is crystal clear now.

sillysaurus3 9y ago
You're taking flak for this, but you're right. When I was doing pentesting, we had an interesting assignment. Our job was to pop a dev project. Then we'd tell them how to secure themselves. One of our tactics was to set up fake Github profiles with very similar names, then try to get someone internal to the team to `git clone` and run our code. Boom, remote shell. We didn't execute the plan. But it was thrown around as an idea. When a package on npm can disappear, and a new package can appear in its place at a later version, by a different author, and there is no connection between those two people, then you're in a bad situation. Just because no one currently runs attacks like this doesn't mean you'll be safe forever. It's worth getting ahead of this. I don't know whether package signing is the best solution. Maybe yes, maybe no. But the question is, if a package vanishes, what is the proper action to take? The solution seems like a rollback. Let us have the latest previous version from the same author, by default. That will fix the builds and not require any heavyweight changes. But package signing would definitely be nice, if it can be integrated in a lightweight and chaos-free fashion.
christophilus 9y ago
Yup. Publishing to Clojars requires GPG and is a bit of a pain compared to publishing to NPM. I'd take Clojar's approach any day of the week to this nonsense, though.

by danjoc 9y ago

sillysaurus3 9y ago

You're taking flak for this, but you're right. When I was doing pentesting, we had an interesting assignment. Our job was to pop a dev project. Then we'd tell them how to secure themselves. One of our tactics was to set up fake Github profiles with very similar names, then try to get someone internal to the team to `git clone` and run our code. Boom, remote shell. We didn't execute the plan. But it was thrown around as an idea. When a package on npm can disappear, and a new package can appear in its place at a later version, by a different author, and there is no connection between those two people, then you're in a bad situation. Just because no one currently runs attacks like this doesn't mean you'll be safe forever. It's worth getting ahead of this. I don't know whether package signing is the best solution. Maybe yes, maybe no. But the question is, if a package vanishes, what is the proper action to take? The solution seems like a rollback. Let us have the latest previous version from the same author, by default. That will fix the builds and not require any heavyweight changes. But package signing would definitely be nice, if it can be integrated in a lightweight and chaos-free fashion.

christophilus 9y ago

Yup. Publishing to Clojars requires GPG and is a bit of a pain compared to publishing to NPM. I'd take Clojar's approach any day of the week to this nonsense, though.