6 ms·
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
by postalcoder 6mo 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.
- mhio 6mo agoand for yarn berry ~/.yarnrc.yml npmMinimalAgeGate: "3d"
- XYen0n 6mo agoIf everyone avoids using packages released within the last 7 days, malicious code is more likely to remain dormant for 7 days.
- DimmieMan 6mo agoThey’re usually picked up by scanners by then.
- cozzyd 6mo agothat's why people are telling others to use 7 days but using 8 days themselves :)
- porridgeraisin 6mo agoGenius
- wongarsu 6mo agobrb, switching everything to 9 days
- johnisgood 6mo agoThat is 3D chess level type shit. xD
- MetaWhirledPeas 6mo agoYou don't have to be faster than the bear, you just have to be faster than the other guy.
- otterley 6mo agoWhat do you base that on? Threat researchers (and their automated agents) will still keep analyzing new releases as soon as they’re published.
- mike_hearn 6mo agoTheir 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).
- narrator 6mo agoA security company could set up a honeypot machine that installs new releases of everything automatically and have a separate machine scan its network traffic for suspicious outbound connections.
- mike_hearn 6mo agoThe problem is what counts as suspicious. StepSecurity are quite clear in their post that they decide what counts as anomalous by comparing lots of open source runs against prior data, so they can't figure it out on their own.
- staticassertion 6mo ago> What do you base that on? The entire history of malware lol
- otterley 6mo agoCan you elaborate? Why do you believe that motivated threat hunters won’t continue to analyze and find threats in new versions of open source software in the first week after release?
- 6mo ago
- jmward01 6mo agoI 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.
- Barbing 6mo ago>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.
- bakugo 6mo ago> 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.
- Aurornis 6mo agoMost people won’t. 7 days gives ample time for security scanning, too.
- 3abiton 6mo agoThis highly depends on the detection mechanism.
- shreyssh 6mo ago[flagged]
- sersi 6mo agoBut 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?
- DrewADesign 6mo agoAnd I’ll bet a chunk of already-compromised vibe coders are feeling really on-top-of-shit because they just put that in their config, locking in that compromised version for a week.
- shreyssh 6mo ago[flagged]
- 131hn 6mo ago[dead]
- superjan 6mo agoAbout 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”.
- weird-eye-issue 6mo agotimeoutMs is shorter ;) You guys can't appreciate a bad joke
- cozzyd 6mo agoMegaseconds are about the right timescale anyway
- torben-friis 6mo agoWhat megaseconds? They clearly meant the Microsoft-defined timeout.
- cozzyd 6mo agoWell megaseconds has the nice property that it's about about equal to a Scaramucci so it can be used across domains.
- sayamqazi 6mo agonot timeout at all is even shorter.
- withinboredom 6mo agotimoutμs is even better. People will learn how to type great symbols.
- johnisgood 6mo agoYes timout indeed!
- 6mo ago
- friendzis 6mo ago> (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?
- gib444 6mo agoOP should be glad a new time unit wasn't invented
- cyrusmg 6mo agoN multiplications of dozen-second
- friendzis 6mo agoWorkdays! 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)
- yohannesk 6mo agoAnd we also need localization. Each country can have their own holidays
- rolandog 6mo agoAnd we need groups of locales for teams that are split across multiple locations; e.g.: new_date = add_workdays( workdays=1.5, start=datetime.now(), regions=["es", "mx", "nl", "us"], )
- zdc1 6mo agoMight be better to calculate them separately for each locale and then tie-break with your own approach (min/max/avg/median/etc.)
- 6mo ago
- WD-42 6mo agoProps to uv for actually using the correct config path jfc what is “bunfig”
- flanbiscuit 6mo agoPnpm 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 https://github.com/npm/cli/releases/tag/v11.10.0
- umko21 6mo agoThe 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?
- ad3xyz 6mo agohttps://docs.astral.sh/uv/concepts/resolution/#dependency-cooldowns 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.
- umko21 6mo agoMy bad. This works for per project configuration, but not for global user configuration.
- js2 6mo agoI think it should work at the user config level too: > If project-, user-, and system-level configuration files are found, the settings will be merged, with project-level configuration taking precedence over the user-level configuration, and user-level configuration taking precedence over the system-level configuration. https://docs.astral.sh/uv/concepts/configuration-files/ https://docs.astral.sh/uv/concepts/configuration-files/
- woodruffw 6mo agoIt should work for global configuration too, please file an issue if you’re observing otherwise. (Make sure you’re on a version that actually supports relative times, please!)
- sbarre 6mo agoThis is what tripped me up. I added that config and then got this error: error: Failed to parse: `.config/uv/uv.toml` Caused by: TOML parse error at line 1, column 17 | 1 | exclude-newer = "7 days" | ^^^^^^^^ failed to parse year in date "7 days": failed to parse "7 da" as year (a four digit integer): invalid digit, expected 0-9 but got I was on version 0.7.20, so I removed that line, ran "uv self update" and upgraded to 0.11.2 and then re-added the config and it works fine now.
- ashishb 6mo agoRun npm/pnpm/bun/uv inside a sandbox. There is no reason to let random packages have full access to your machine
- bbkane 6mo agoSandboxing by to default world be really nice. One of the things I really appreciate about Claude Code is its permissions model
- novachen 6mo ago[dead]
- cvak 6mo agoI think the npm doesn't support end of line comments, so ~/.npmrc min-release-age=7 # days 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 ¯\_(ツ)_/¯
- cvak 6mo agook, it works, only the list function shows it as null...
- imhoguy 6mo agoGood luck with any `npm audit` in a pipeline. Sometimes you have to pull the latest release because the previous one had a critical vulnerability.
- sspiff 6mo agoIt'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.
- zelphirkalt 6mo agoIf 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.
- po1nt 6mo agoThat would likely mean same amount of people get the vulnerability, just 7 days later.
- user34283 6mo agoThe compromised packages were removed from the registry within hours.
- brabel 6mo agoBecause everyone got updates immediately. If the default was 7 days, almost no one would get updates immediately but after 7 days, and now someone only finds about after 7 days. Unless there is a poor soul checking packages as they are published that can alert the registry before 7 days pass, though I imagine very few do that and hence a dedicated attacker could influence them to not look too hard.
- Leherenn 6mo agoIf I remember correctly, in all the recent cases it was picked up by automated scanning tools in a few hours, not because someone updated the dependency, checked the code and found the issue. So it looks like even if no one actually updates, the vast majority of the cases will be caught by automated tools. You just need to give them a bit of time.
- cowl 6mo agomin 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
- ksnssjsjsj 6mo agoOut of the frying pan and into the frier.....
- freedomben 6mo agoExactly 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.
- aetherspawn 6mo agoNot really an issue though right because virtually none of these have lasted more than 1-2 days before being discovered?
- tytho 6mo agoAt 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 https://pnpm.io/settings#minimumreleaseageexclude
- n_e 6mo agoI haven't checked, but it would be surprising that the min-release-age applies to npm audit and equivalent commands
- CGamesPlay 6mo agoThe 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.
- powerpixel 6mo agoIs 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 :))
- shreyssh 6mo ago[flagged]
- antihero 6mo agonpm is claiming this doesn’t exist
- sbarre 6mo agoMake sure you're on version 11.10 or later?
- jdxcode 6mo agolol with mise I used a fourth time unit: https://mise.jdx.dev/configuration/settings.html#install_before https://mise.jdx.dev/configuration/settings.html#install_bef...
- xenophonf 6mo agoWhere in the pnpm documentation does it say that it ignores scripts by default? From https://pnpm.io/cli/install#--ignore-scripts https://pnpm.io/cli/install#--ignore-scripts: > Default: *false*
- moebrowne 6mo agoWeird. The config also appears to default to `false` https://pnpm.io/settings#ignorescripts https://pnpm.io/settings#ignorescripts
- simonkagedal 6mo agoThis page describes the behavior, "disables the automatic execution of postinstall scripts in dependencies": https://pnpm.io/supply-chain-security 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).
- yonarbel 6mo ago[dead]
- dt3ft 6mo agoAnd 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.
- cortesoft 6mo agoWho will do the vetting process?
- password4321 6mo agoI 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).
- pvillano 6mo agoJia Tan
- matijs 6mo agopnpm since v10.19.0 allows excluding specific dependencies from minReleaseAge by version.
- deleted 6mo ago[deleted]
- paulddraper 6mo agoEveryone has forgotten standard ISO 8601 durations and invented their own syntax.
- diarrhea 6mo agouv supports it, https://docs.astral.sh/uv/reference/settings/#exclude-newer https://docs.astral.sh/uv/reference/settings/#exclude-newer
- paulddraper 6mo agoPerfect
- robrain 6mo agomise has an option as well (note the caveats though): https://mise.jdx.dev/configuration/settings.html#install_before https://mise.jdx.dev/configuration/settings.html#install_bef... And homebrew has discussed it, kinda sorta: https://github.com/Homebrew/brew/issues/21129 https://github.com/Homebrew/brew/issues/21129
- cxr 6mo ago> 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=46006471 https://news.ycombinator.com/item?id=46006471> <https://news.ycombinator.com/item?id=46360308 https://news.ycombinator.com/item?id=46360308>
- melroy89 6mo ago`~/Library/Preferences/pnpm/rc` reads like is MacOS.. I'm using Linux...?
- aorth 6mo agoWhat version of npm has this? This isn't working for me on npm 11.6.2 (Node v24): ~/.npmrc min-release-age=7 # days