4 ms·

> Maybe part of the 0-day fix is go multiparty: allow weighted votes by dependents to take over the namespace to force a patch/reversion. You own your code etc,

> Maybe part of the 0-day fix is go multiparty: allow weighted votes by dependents to take over the namespace to force a patch/reversion. You own your code etc, but the OSS distro service has its own community-owned rules, and you are free to run a competing package manager without them. Not a good idea. You are pretty much asking to be review bomb. You would need very good moderation to be able to trust votes. That means npm spending a bunch of resources on hiring them, not sure if they are up for that (no, free mods aren't the solution).

lmeyerov 5y ago
Yep, so build in adversarial controls like thresholding. The status quo is already beyond what gh/npm are managing: they already need the mods they aren't hiring. Scanners are helping, but a big part of GH is community tools, so weird not to figure it out here too.
- patmorgan23 5y ago
  Or you could just pin to a specific version and not update until you test.
  - lmeyerov 5y ago
    Those both have their own scaling issues, so not as clear of a step forward. Ex: We pin & package lock our versions, but it's harder for libraries to (they should do ranges), including ones we release. Likewise, for our apps (non-libraries), updating pinned package locks is reasonable for our direct dependencies, nested dependencies are hard to really have confidence on. Colors and leftpad both exemplify this: both projects fail our standards for direct dependencies, so the concern is nested ones. Unlike apt, we don't want super stale versions of everything. For stuff like security, defense in depth + minimal targeted mechanisms for targeted threat models are generally a win, and I think that applies here for mitigating rogue releases by rogue package owners. Shifts like bitcoin -- crypto mining, ransomware, and wallet theft -- have made stuff like package buyouts and sneaky patches a reality where we must 'assume breach' of bad releases, not just try to prevent.
- dylan-m 5y ago
  Alternatively, instead of a futile attempt to reinvent the universe, services like NPM could stop pretending that dependencies are easy. They should be encouraging people to pin versions, keep track of updates, and avoid packages with poorly defined dependencies of their own.

lmeyerov 5y ago

Yep, so build in adversarial controls like thresholding. The status quo is already beyond what gh/npm are managing: they already need the mods they aren't hiring. Scanners are helping, but a big part of GH is community tools, so weird not to figure it out here too.

patmorgan23 5y ago
Or you could just pin to a specific version and not update until you test.
- lmeyerov 5y ago
  Those both have their own scaling issues, so not as clear of a step forward. Ex: We pin & package lock our versions, but it's harder for libraries to (they should do ranges), including ones we release. Likewise, for our apps (non-libraries), updating pinned package locks is reasonable for our direct dependencies, nested dependencies are hard to really have confidence on. Colors and leftpad both exemplify this: both projects fail our standards for direct dependencies, so the concern is nested ones. Unlike apt, we don't want super stale versions of everything. For stuff like security, defense in depth + minimal targeted mechanisms for targeted threat models are generally a win, and I think that applies here for mitigating rogue releases by rogue package owners. Shifts like bitcoin -- crypto mining, ransomware, and wallet theft -- have made stuff like package buyouts and sneaky patches a reality where we must 'assume breach' of bad releases, not just try to prevent.
dylan-m 5y ago
Alternatively, instead of a futile attempt to reinvent the universe, services like NPM could stop pretending that dependencies are easy. They should be encouraging people to pin versions, keep track of updates, and avoid packages with poorly defined dependencies of their own.