3 ms·

Any thoughts on how these situations could be automatically detected by a third party given the current realities of the JS ecosystem? Here are some quick ideas

by tlack 8y ago

Any thoughts on how these situations could be automatically detected by a third party given the current realities of the JS ecosystem? Here are some quick ideas: 1. Detect commits that are radically different from previous ones in the same repo by some measure (tricky) 2. Detect npm publish events whose contents are different than source repo 3. Detect author/ownership changes in the context of npm packages What else?

tracker1 8y ago
Require all public packages published from accessible source code built/compiled by the package repository project directly... This would have the side effect of requiring likely paid exceptions for popular binary packages or those that have more complex build requirements. However, the vast majority of npm packages could probably be built via some form of template. npm test - must have a configured script in package.json and must not error (this is easy enough to work around, but should be required) npm run build - should be added as a required step, where the output to be packaged is outputted process.env.BUID_OUTPUT as a directory. This would at the very least minimize some of the risks... signed commits could be an additional step, but coordination to make tooling for this easier to use would have to happen. Also, ownership changes should have a FREEZE only allowing a new Major release after transfer of a package.
takinola 8y ago
What does it mean to have an npm publish event content be different than the source repo? Doesn't npm publish just "push" the source repo to npm?
inimino 8y ago
The problem is that if you import 1000 packages by 500 different authors, you must trust 500 authors. You must trust them not only to not be malicious, but not to have been compromised. How can there be an automated solution to this problem? The only solution is to develop some discipline around dependencies. Unfortunately the current culture around Node/NPM has gone in the opposite direction.

by tlack 8y ago

tracker1 8y ago

Require all public packages published from accessible source code built/compiled by the package repository project directly... This would have the side effect of requiring likely paid exceptions for popular binary packages or those that have more complex build requirements. However, the vast majority of npm packages could probably be built via some form of template. npm test - must have a configured script in package.json and must not error (this is easy enough to work around, but should be required) npm run build - should be added as a required step, where the output to be packaged is outputted process.env.BUID_OUTPUT as a directory. This would at the very least minimize some of the risks... signed commits could be an additional step, but coordination to make tooling for this easier to use would have to happen. Also, ownership changes should have a FREEZE only allowing a new Major release after transfer of a package.

takinola 8y ago

What does it mean to have an npm publish event content be different than the source repo? Doesn't npm publish just "push" the source repo to npm?

inimino 8y ago

The problem is that if you import 1000 packages by 500 different authors, you must trust 500 authors. You must trust them not only to not be malicious, but not to have been compromised. How can there be an automated solution to this problem? The only solution is to develop some discipline around dependencies. Unfortunately the current culture around Node/NPM has gone in the opposite direction.