51–60 of 152 posts
If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
I think uv should get some credit for being an early supporter of this. They originally added it as a hidden way to create stable fixtures for their own tests, but it has become a pretty popular flag to use. This for instance will only install packages that are older than 14 days: uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ') It's great to see this kind of stuff being adopted in more places.
Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects tha…
Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…
name + version are immutable, you can't republish packages in npm under existing version. you can only unpublish. content hash integrity is verified in lockfiles. the problem is with dependencies using semver ranges, especially wide ones like "debug": "*" initiatives like provenance statements [0] / code signing are also good complement to delayed dependency updates. also not running as default / whitelisting postins…
The only immutability that counts is immutability that you can verify, which brings us back to cryptographic hashes.
Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…
The problem here isn't, "someone introduced malware into an existing version of a package". The problem is, "people want to stay up to date, so when a new patch version is released, everyone upgrades to that new patch version".
Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.
Or just use ISO8601 standard notation (e.g. "P1D" for one day)
oh, you can use commas too.
and if you're still not thinking this is fun, here's a quote from Wikipedia "But keep in mind that "PT36H" is not the same as "P1DT12H" when switching from or to Daylight saving time."
just add a unit to your period parameters. sigh.
If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
Its not a bad idea, might help in certain cases. But the real solution to this kind of attack is to stop resolving packages by name and instead resolve them by hash, then binding a name to that hash for local use. That would of course be a whole different, mostly unexplored, world, but there's just no getting around the fact that blindly accepting updated versions of something based on its name is always going to cre…
Resolving by hash is a half solution at best. Not having automated dependency upgrades also has severe security downsides. Apart from that, lock files basically already do what you describe, they contain the hashes and the resolution is based off the name while the hash ensures for the integrity of the resolved package. The problem is upgrade automation and supply chain scanning. The biggest issue there is that scann…
As for lock files, they prevent skulduggery after the maintainer has said "yeah, I trust this thing and my users should too" but the attacks we're seeing is upstream of that point because maintainers are auto-trusting things based on their name+version pair, not based on their contents.
The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.