This sort of mitigation seems like it makes sense in the short term, but it seems like it would only work as long as most people don't do it. If everyone has this set to seven days, it will take seven days plus three hours to get things yanked, and then there will be people who will set to 14 days...
1) Package owners will often realise they've been hacked quickly, since there are releases they never authorised. This gives them plenty of time to raise the alarm and yank the packages
2. Independent security researchers and other automated vulnerability scans will still be checking the latest releases even if users aren't using them
Yes it's not a perfect defense but it would help a lot.
These malicious packages are being caught by the authors, and by automated package security scanners, not just by end users. npm should start setting this 7 day cooldown as default.
Some people would set up tooling to look for compromises the moment they get published. What's neat about this is that as an attacker you have no way to determine beforehand whether you'll get caught by this. So you would run your attack, it would lead to a compromised package being published, then the world would get a chance to look at it and see if they can detect the issue with it. This would of course lead to attackers being a lot sneakier. But I think due to the opaque nature of what checks people are running against packages and what they might notice, a much smaller number of attacks would make it through. Of course the ones that did by definition would be the ones that were impossible to detect and would thus stick around a lot longer.
you are betting that the package is popular, has enough eyes to mitigate attack in 7 days. attackers could also target unpopular packages for long game
In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default).
It has the strongest security posture of any node pm.
Heads up: Your website at en.dev says you're a one-person open source company. That immediately ruled out any of your tools for me and my team; no matter how great they may be, a single developer is a supply chain risk. I wholeheartedly recommend enlarging the team.
What a pleasant surprise to see jdx within comments! I was actually using mise and found aube and decided to publish it on hackernews, I found it really cool!
Though a bit sad that it hadn't received traction back then but I must admit jdx that a lot of the work that you do is really cool.
Also I am happy to know that you are finally able to work on Open source full time, I am glad that I can use open source software created by (in my opinion generous) people like you too, mise is awesome :-D
This confused me too, until I realized that the article is about pnpm, not npm (pnpm reads .npmrc for some reason, despite not having the same options as npm)
On a related note, it seems to be impossible to find the documentation of min-release-age by googling it. Very annoying.
I just set this up for npm, here's the command that worked for me:
npm config set min-release-age 7
The '7' is days. This is the only format that worked for me, just a single integer number of days.
Confirmed by trying to install the latest version of React 19.2.6 (published 5 days ago as of the time of this comment). It failed with a comment confirming that it could not find such a version published before a week ago.
Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.
You aren't wrong. However, this article does offer some additional advice on this matter, and some potential reasons why it might still be desirable to pin your deps in package.json.
> If a lock file gets out of sync with its package.json, it can no longer be guaranteed to lock anything, and the package.json will be the source of truth for installs.
> provides much less visibility than package.json, because it's not designed to be human readable and is quite dense.
> If the package.json has a range, and a new in-range version is released that would break the build, then essentially your package.json is in a state of "broken", even if the lock file is still holding things together.
Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster.
And then use distro packages.
(I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)
Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`.
I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.
> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish.
This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication.
For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.
- Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik.
- The bin package manager lets you pin binaries, but they aren't hash-pinned either.
- The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin
Funny you ask. This project started as a very different project almost five years ago. It was called roarr.io, and the primary purpose was exactly that: adhoc collecting logs from remote machines. However, I've not ported this functionality (yet).
That would require restarting your services to redirect their output. Fine for one-off scripts, but impractical when you have long-running processes and don't want to restart them every time an agent needs to read logs.
With teemux, a persistent MCP server gives multiple AI agents access to logs as needed—without interrupting your development flow.
OK, but it isn't like agents react to flowing logs, they just connect to whatever server and query the past 5 minutes or 2 hours on demand depending on the debugging task at hand without mixing contexts together.
Pronounced tmux. That's a thing. A very related thing. A very well-known thing. It's a bad name. I do like the concept though (haven't tried using it yet).
https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...
Just a handful of settings to save a whole lot of trouble.