Comment by postalcoder
25 days ago
PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages.
I also have `ignore-scripts=true` in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. bun and pnpm do not execute lifecycle scripts by default.
Here's how to set global configs to set min release age to 7 days:
~/.config/uv/uv.toml
exclude-newer = "7 days"
~/.npmrc
min-release-age=7 # days
ignore-scripts=true
~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes
~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds
(Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)
If you're developing with LLM agents, you should also update your AGENTS.md/CLAUDE.md file with some guidance on how to handle failures stemming from this config as they will cause the agent to unproductively spin its wheels.
> (Side note, it's wild that npm, bun, and pnpm have all decided to use different time units for this configuration.)
First day with javascript?
You mean first 86,400 seconds?
You have to admire the person who designed the flexibility to have 87239 seconds not be old enough, but 87240 to be fine.
34 replies →
wait what if we start on a day DST starts or ends????
OP should be glad a new time unit wasn't invented
Workdays! Think about it, if you set the delay in regular days/seconds the updated dependency can get pulled in on a weekend with only someone maybe on-call.
(Hope your timezones and tzdata correctly identifies Easter bank holiday as non-workdays)
25 replies →
If we're taking suggestions, I'd like to propose "parsec" (not to be confused with the unit of distance of the same name)
That way Han Solo can make sense in the infamous quote.
EDIT: even Gemini gets this wrong:
> In Star Wars, a parsec is a unit of distance, not time, representing approximately 3.26 light-years
6 replies →
N multiplications of dozen-second
To me it sounds safer to have different big infra providers with different delays, otherwise you still hit everyone at the same time when something does inevitably go undetected.
And the chances of staying undetected are higher if nobody is installing until the delay time ellapses.
It's the same as not scheduling all cronjobs to midnight.
About the use of different units: next time you choose a property name in a config file, include the unit in the name. So not “timeout” but “timeoutMinutes”.
Yes!! This goes for any time you declare a time interval variable. The number of times I've seen code changes with a comment like "Turns out the delay arg to function foo is in milliseconds, not seconds".
Or require the value to specify a unit.
At that point, you're making all your configuration fields strings and adding another parsing step after the json/toml/yaml parser is done with it. That's not ideal either; either you write a bunch of parsing code (not terribly difficult but not something I wanna do when I can just not), or you use some time library to parse a duration string, in which case the programming language and time library you happen to use suddenly becomes part of your config file specification and you have to exactly re-implement your old time handling library's duration parser if you ever want to switch to a new one or re-implement the tool in another language.
I don't think there are great solutions here. Arguably, units should be supported by the config file format, but existing config file formats don't do that.
5 replies →
timeoutMs is shorter ;)
You guys can't appreciate a bad joke
Megaseconds are about the right timescale anyway
2 replies →
timoutμs is even better. People will learn how to type great symbols.
2 replies →
not timeout at all is even shorter.
Pnpm did this first but I’m glad to see all the others follow suit
For anyone wondering, you need to be on npm >= 11.10.0 in order to use it. It just became available Feb 11 2026
https://github.com/npm/cli/releases/tag/v11.10.0
Is there a way to do that per repo for these tools ? We all know how user sided configuration works for users (they usually clean it whenever it goes against what they want to do instead of wondering why it blocks their changes :))
At least with npm, you can have a .npmrc per-repo
Fairly sure every single one has a repo level config that you can add these settings to. Others have pointed out the pnpm and npm, and I bunfig can also be repo level.
pnpm does global + per-repo
> PSA: npm/bun/pnpm/uv now all support setting a minimum release age for packages.
The solution is not moar toolz. That's the problem—this crazy mindset that the problems endemic to bad tooling have a solution in the form of complementing them with another layer, rather than fewer.
Git and every sane SCM already allow you to manage your source tree without jumping through a bunch of hoops to go along with wacky overlay version control systems like the one that the npmjs.com crew designed, centering around package.json as a way to do an end-run around Git. You don't need to install and deploy anything containing never-before-seen updates just because the NodeJS influencer–developers say that lockfiles are the Right Way to do things. (It's not.)
Opting in to being vulnerable to supply chain attacks is a choice.
<https://news.ycombinator.com/item?id=46360308>
min release age to 7 days about patch releases exposes you to the other side of the coin, you have an open 7 days window on zero-day exploits that might be fixed in a security release
The packages that are actually compromised are yanked, but I assume you're talking about a scenario more like log4shell. In that case, you can just disable the config to install the update, then re-enable in 7 days. Given that compromised packages are uploaded all the time and zero-day vulnerabilities are comparatively less common, I'd say it's the right call.
`uv` has per-package overrides, I imagine there may be similar in other managers
At least with pnpm, you can specify minimumReleaseAgeExclude, temporarily until the time passes. I imagine the other package managers have similar options.
[1]: https://pnpm.io/settings#minimumreleaseageexclude
I haven't checked, but it would be surprising that the min-release-age applies to npm audit and equivalent commands
Not really an issue though right because virtually none of these have lasted more than 1-2 days before being discovered?
Out of the frying pan and into the frier.....
Exactly what I thought too when I read this...
Urgent fix, patch released, invisible to dev team cause they put in a 7 day wait. Now our app is vulnerable for up to 7 days longer than needed (assuming daily deploys. If less often, pad accordingly). Not a great excuse as to why the company shipped an "updated" version of the app with a standing CVE in it. "Sorry we were blinded to the critical fix because set an arbitrary local setting to ignore updates until they are 7 days old". I wouldn't fire people over that, but we'd definitely be doing some internal training.
It's wild that none of these are set by default.
I know 90% of people I've worked with will never know these options exist.
That would likely mean same amount of people get the vulnerability, just 7 days later.
The compromised packages were removed from the registry within hours.
2 replies →
If everyone or a majority of people sets these options, then I think issues will simply be discovered later. So if other people run into them first, better for us, because then the issues have a chance of being fixed once our acceptable package/version age is reached.
Where in the pnpm documentation does it say that it ignores scripts by default?
From https://pnpm.io/cli/install#--ignore-scripts:
> Default: *false*
Weird. The config also appears to default to `false`
https://pnpm.io/settings#ignorescripts
This page describes the behavior, "disables the automatic execution of postinstall scripts in dependencies":
https://pnpm.io/supply-chain-security
While this explicitly calls out "postinstall", I'm pretty sure it affects other such lifecycle scripts like preinstall in dependencies.
The --ignore-scripts option will ignore lifecycle scripts in the project itself, not just dependencies. And it will ignore scripts that you have previously allowed (using the "allowBuilds" feature).
and for yarn berry
And when you actually need a super hot fix for a 0-day, you will need to revert this and keep it that way for some time to then go back to minimum age.
While this works, we stillneed a permanent solution which requires a sort of vetting process, rather than blindly letting everything through.
pnpm since v10.19.0 allows excluding specific dependencies from minReleaseAge by version.
Who will do the vetting process?
I think my vetting would settle for a repo diff against the previous version, confirming the only difference was the security fix (though that doesn't cover all the bases).
Jia Tan
mise has an option as well (note the caveats though):
https://mise.jdx.dev/configuration/settings.html#install_bef...
And homebrew has discussed it, kinda sorta:
https://github.com/Homebrew/brew/issues/21129
Run npm/pnpm/bun/uv inside a sandbox.
There is no reason to let random packages have full access to your machine
Sandboxing by to default world be really nice. One of the things I really appreciate about Claude Code is its permissions model
lol with mise I used a fourth time unit: https://mise.jdx.dev/configuration/settings.html#install_bef...
Everyone has forgotten standard ISO 8601 durations and invented their own syntax.
uv supports it, https://docs.astral.sh/uv/reference/settings/#exclude-newer
Perfect
What version of npm has this? This isn't working for me on npm 11.6.2 (Node v24):
I think the npm doesn't support end of line comments, so
actually doesn't set it at all, please edit your comment.
EDIT: Actually maybe it does? But it's weird because
`npm config list -l` shows: `min-release-age = null` with, and without the comment. so who knows ¯\_(ツ)_/¯
ok, it works, only the list function shows it as null...
If everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
What do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
Their analysis was triggered by open source projects upgrading en-masse and revealing a new anomalous endpoint, so, it does require some pioneers to take the arrows. They didn't spot the problem entirely via static analysis, although with hindsight they could have done (missing GitHub attestation).
2 replies →
The fact threat researchers and especially their automated agents are not all that good at their jobs
2 replies →
> What do you base that on?
The entire history of malware lol
4 replies →
that's why people are telling others to use 7 days but using 8 days themselves :)
brb, switching everything to 9 days
1 reply →
You don't have to be faster than the bear, you just have to be faster than the other guy.
Genius
I suspect most packages will keep a mix of people at 7 days and those with no limit. That being said, adding jitter by default would be good to these features.
>adding jitter by default would be good
This became evident, what, perhaps a few years ago? Probably since childhood for some users here but just wondering what the holdup is. Lots of bad press could be avoided, or at least a little.
They’re usually picked up by scanners by then.
> If everyone avoids using packages released within the last 7 days
Which will never even come close to happening, unless npm decides to make it the default, which they won't.
Most people won’t.
7 days gives ample time for security scanning, too.
This highly depends on the detection mechanism.
[flagged]
But wouldn't the type of people that notifes anomalous network activity be exactly the type of people who add a 7 day delay because they're security conscious?
2 replies →
[dead]
Props to uv for actually using the correct config path jfc what is “bunfig”
Silly portmanteau of "bun" and "config"
A trendy sandwich
`~/Library/Preferences/pnpm/rc` reads like is MacOS.. I'm using Linux...?
The config for uv won't work. uv only supports a full timestamp for this config, and no rolling window day option afaik. Am I crazy or is this llm slop?
https://docs.astral.sh/uv/concepts/resolution/#dependency-co...
> Define a dependency cooldown by specifying a duration instead of an absolute value. Either a "friendly" duration (e.g., 24 hours, 1 week, 30 days) or an ISO 8601 duration (e.g., PT24H, P7D, P30D) can be used.
My bad. This works for per project configuration, but not for global user configuration.
5 replies →
Good luck with any `npm audit` in a pipeline. Sometimes you have to pull the latest release because the previous one had a critical vulnerability.
npm is claiming this doesn’t exist
Make sure you're on version 11.10 or later?
[dead]
[flagged]
[dead]