6 ms·

pnpm just added this: https://pnpm.io/blog/releases/10.16 https://pnpm.io/blog/releases/10.16

jauntywundrkind 1y ago
minimumReleaseAge is pretty good! Nice!! I do wish there were some lists of compromised versions, that package managers could disallow from.
thepill 1y ago
bun is also working on it: https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679
philipwhiuk 1y ago
Aren't they found quickly because people upgrade quickly?
drdaeman 1y ago
This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.
- brw 1y ago
  These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev https://socket.dev or https://snyk.io https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses. Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well. Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here. > The responsibility lies with
- kelnos 1y ago
  No, it doesn't solve the issue, but it probably helps. And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.
- dec0dedab0de 1y ago
  a long enough delay would solve the issue for account takeovers, and bold attacks like this. It would not solve for a bad actor gaining trust over years, then contributing seemingly innocent code that contains an exploitable bug with enough plausible deniability to remain on the team after it is patched.
brw 1y ago
there's apparently an npm RFC from 2022 proposing a similar (but potentially slightly better?) solution https://github.com/npm/rfcs/issues/646 https://github.com/npm/rfcs/issues/646
smrtinsert 1y ago
this btw would also solve social media. if only accounts required a month waiting period before they could speak.

minimumReleaseAge is pretty good! Nice!! I do wish there were some lists of compromised versions, that package managers could disallow from.

thepill 1y ago

bun is also working on it: https://github.com/oven-sh/bun/issues/22679 https://github.com/oven-sh/bun/issues/22679

philipwhiuk 1y ago

Aren't they found quickly because people upgrade quickly?

drdaeman 1y ago

This sounds nice in theory, but does it really solve the issue? I think that if no one's installing that package then no one is noticing the malware and no one is reporting that package either. It merely slightly improves the chances that author would notice a version they didn't release, but this doesn't work if author is not particularly actively working the compromised project.

brw 1y ago
These days compromised packages are often detected automatically by software that scans all packages uploaded to npm like https://socket.dev https://socket.dev or https://snyk.io https://snyk.io. So I imagine it's still useful to have those services scan these packages first, before they go out to the masses. Measures like this also aren't meant to be "final solutions" either, but stop-gaps. Slowing the spread can still be helpful when a large scale attack like this does occur. But I'm also not entirely sure how much that weighs against potentially slowing the discovery as well. Ultimately this is still a repository problem and not a package manager one. These are merely band-aids. The responsibility lies with npm (the repository) to implement proper solutions here. > The responsibility lies with
kelnos 1y ago
No, it doesn't solve the issue, but it probably helps. And I agree that if everyone did this, it would slow down finding issues in new releases. Not really sure what to say to that... aside from the selfish idea that if I do it, but most other people don't, it won't affect me.
dec0dedab0de 1y ago
a long enough delay would solve the issue for account takeovers, and bold attacks like this. It would not solve for a bad actor gaining trust over years, then contributing seemingly innocent code that contains an exploitable bug with enough plausible deniability to remain on the team after it is patched.

brw 1y ago

there's apparently an npm RFC from 2022 proposing a similar (but potentially slightly better?) solution https://github.com/npm/rfcs/issues/646 https://github.com/npm/rfcs/issues/646

smrtinsert 1y ago

this btw would also solve social media. if only accounts required a month waiting period before they could speak.