5 ms·

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions

Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can work, 3 days is ok, 7 days is a bit of an overkill but works too) How to set them up? - use latest pnpm, they added 1 day cooldown by default https://pnpm.io/supply-chain-security https://pnpm.io/supply-chain-security - or if you want a one click fix, use https://depsguard.com https://depsguard.com (cli that adds cooldowns + other recommended settings to npm, pnpm, yarn, bun, uv, dependabot and, disclaimer: I’m the maintainer) - or use https://cooldowns.dev https://cooldowns.dev which is more focused on, well, cooldowns, with also a script to help set it up locally All are open source / free. If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, but each of them have a way to do so (described in detail in depsguard.com / cooldowns.dev) In the past few months, while I don't have hard numbers, it seems more risk has come from Software Supply Chain attacks (malicious versions pushed) than from new zero day CVEs (even in the age of Mythos driven vulnerability discovery)

Normal_gaussian 4mo ago
> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.
- eranation 4mo ago
  I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption. So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
  - hedora 4mo ago
    In what way is "edit your .npmrc" simple?!? The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc. Every one of those has a different opinion about how to spell "cooldown". On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)
    - seattle_spring 4mo ago
      > The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc. This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
  - StilesCrisis 4mo ago
    An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.
  - Normal_gaussian 4mo ago
    > Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code. > So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :) I'm struggling to find a non-contrived group of people who: - do not know how to open and edit a file on their system - do use npm - would find installing pnpm or running `sudo install -d -m 0755 /etc/apt/keyrings; curl -fsSL https://depsguard.com/apt/gpg.key https://depsguard.com/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/depsguard.gpg; echo "deb [signed-by=/etc/apt/keyrings/depsguard.gpg] https://depsguard.com/apt https://depsguard.com/apt stable main" | sudo tee /etc/apt/sources.list.d/depsguard.list >/dev/null; sudo apt update; sudo apt install depsguard` simpler Of course, cooldowns.dev is a very long winded way of telling someone to run `npm config set min-release-age=3`, which is the simplest.
pavel_lishin 4mo ago
A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening https://github.com/jordanconway/package-manager-hardening
- nicolewhite 4mo ago
  From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.
  - eranation 4mo ago
    In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.
  - throwawayffffas 4mo ago
    Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well. That's where the lockfile comes in, it pins the dependencies of the dependencies.
    - stavros 4mo ago
      Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.
doctorpangloss 4mo ago
> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
- eranation 4mo ago
  I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs - pnpm just adopted 24 hours cooldown as default, based on community feedback.
  - doctorpangloss 4mo ago
    what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
    - eranation 4mo ago
      It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
      - deleted 4mo ago
        [deleted]
    - 4mo ago
make3 4mo ago
theoretical question, do cooldowns still work if everyone has them?
- ZiiS 4mo ago
  Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.
  - saghm 4mo ago
    I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
    - enedil 4mo ago
      Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
      - saghm 4mo ago
        You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
- chillax 4mo ago
  Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
  - cluckindan 4mo ago
    It’s kind of insane this doesn’t happen in the publish pipeline by default.
darig 4mo ago
[dead]
QuiEgo 4mo ago
As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.
- smrtinsert 4mo ago
  There's literally no excuse - I'm still baffled.
  - scorpioxy 4mo ago
    You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not. And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here. I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
    - oasisbob 4mo ago
      I think the post you're replying to was commenting on "web dev is a culture shock in so many ways", not the concept of cooldowns overall.
- schonfinkel 4mo ago
  I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
  - 4mo ago
k_sze 4mo ago
Nice work! Is there a sensible way to add a cooldown to Docker/Podman image pulling?
TacticalCoder 4mo ago
> Hope it's ok I hijack this thread again about setting up cooldowns... In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities). It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature". Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using). And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes. Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else. Such new package releases are easier to audit by security researchers.
- collinmanderson 4mo ago
  > no cooldown (or a much smaller countdown) for security fixes. A supply chain attack would likely able to publish a "security" release just as easily as a normal release, so I don't think that would help much.
naruhodo 4mo ago
> but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. I'm not letting gam gams anywhere near that shit. She can continue writing her own apps in assembly language - it's good for her brain health!

Normal_gaussian 4mo ago

> If you know how to edit your ~/.npmrc etc, you don't really need any of them, but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. This feels like a very very small group of people; and people who really could do with opening the file and adding the line.

eranation 4mo ago
I wish that was the case. Asking people to do something simple, doesn't matter how simple it is, depends on how simple they view it. Changing your own car's oil is actually not that hard, once you know how to do it, most people don't even try. Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. In any funnel, each step, no matter how easy, adds friction, remove the friction and you get bigger adoption. So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :)
- hedora 4mo ago
  In what way is "edit your .npmrc" simple?!? The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc. Every one of those has a different opinion about how to spell "cooldown". On top of that, there's the bootstrapping issue of "I want to install the N pieces of ecosystem sprawl that read the .[p]npmrc that have the cooldown directive in them. How do I do that with a cooldown?" (Where N is unknowable, because of course it is.)
  - seattle_spring 4mo ago
    > The JS ecosystem is really, really complicated, so any non-trivial app is going to use multiple bundlers, node runtimes, native runtimes, etc, etc, etc. This statement makes very little sense to me. I've worked on several of what are likely the largest JS monorepos in the world, and they all define a specific version of a specific runtime and package manager you should be using.
- StilesCrisis 4mo ago
  An extra $15 of labor is well worth the cost of not having to change my own oil. They will do it efficiently and won't break anything. The cost of messing up one time immediately cancels out a lifetime of DIY savings, and they are equipped to do it right.
- Normal_gaussian 4mo ago
  > Changing your own car's oil is actually not that hard It is. Changing oil requires a place where you have sufficient access to the vehicle to drain it; the right equipment; the right disposal solutions. Most people who have cars do not have that. And it takes significantly more time to change your own oil than to have someone else do it as part of other specialist maintenance. > Think of QR codes, people hardly used them for many years, because you needed to download an app for it, small step. It only started to catch up when you had it built in the camera app in most providers. Exactly. Using a QR code app required specific knowledge of the app, an internet connection, some time, knowledge of how and when to use it, and something to use it with - the barrier of which surpassed the convenience gained from the QR code. > So yes, everyone could open a file and edit it, also everyone could watch a youtube video on how to do X and yet choose to have someone else do it for them :) I'm struggling to find a non-contrived group of people who: - do not know how to open and edit a file on their system - do use npm - would find installing pnpm or running `sudo install -d -m 0755 /etc/apt/keyrings; curl -fsSL https://depsguard.com/apt/gpg.key https://depsguard.com/apt/gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/depsguard.gpg; echo "deb [signed-by=/etc/apt/keyrings/depsguard.gpg] https://depsguard.com/apt https://depsguard.com/apt stable main" | sudo tee /etc/apt/sources.list.d/depsguard.list >/dev/null; sudo apt update; sudo apt install depsguard` simpler Of course, cooldowns.dev is a very long winded way of telling someone to run `npm config set min-release-age=3`, which is the simplest.

pavel_lishin 4mo ago

A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening https://github.com/jordanconway/package-manager-hardening

nicolewhite 4mo ago
From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing across installs -- it's the lockfile that accomplishes this.
- eranation 4mo ago
  In most cases yes, but really depends on which package manager and what command, if you use npm ci, it uses the package-lock.json values, if you use npm install, it can use any levels of freedom in the package.json. So if you lock package.json you remove that degree of freedom. But sometimes you do want to be able to "recreate the lock file" since it does fix a CVE. Just with a lockdown, you'll get the legitimate patch vs an accidental malicious takeover.
- throwawayffffas 4mo ago
  Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well. That's where the lockfile comes in, it pins the dependencies of the dependencies.
  - stavros 4mo ago
    Lockfiles serve multiple purposes. For example, some include hashes so you aren't served altered packages from the package registry. I agree with you otherwise, though.

doctorpangloss 4mo ago

> Caveat - if you need to patch a new critical CVE, you need to bypass the cooldown, by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.

eranation 4mo ago
I don't agree that nobody is adopting them. Can you please elaborate? - Most companies I know have a 24 hours (at least) cooldown via their Artifactory / Nexus. They have ways to bypass it for urgent CVEs - pnpm just adopted 24 hours cooldown as default, based on community feedback.
- doctorpangloss 4mo ago
  what is the difference between these two things from the point of view of how much work you have to do? - checking every update of every dependency to see if is a relevant urgent security update - checking every update of every dependency to see if it turns out to be a supply chain exploit am i still checking every update of every dependency? there's no heuristic here. either you check them all, or you get randomly exploited - either by using known vulnerable software or from supply chain attacked software.
  - eranation 4mo ago
    It's a tradeoff, and I don't have hard data, but the cases where a reachable, exploitable, zero day CVE that requires an urgent immediate patch (usually unintentional vulnerability) vs complete dev machine / CI/CD takeover of a supply chain attack (malicious intent) - show that a 7 day cooldown (or even 24 hours) would be the safe choice. I should probably consider doing this research, didn't get to it yet.
    - deleted 4mo ago
      [deleted]
  - 4mo ago

make3 4mo ago

theoretical question, do cooldowns still work if everyone has them?

ZiiS 4mo ago
Less well maybe but yes. Security researchers still proactively test them, and the maintainer has a much better chance of catching it themselves.
- saghm 4mo ago
  I'd argue that we don't actually know if this is the case or not because we haven't yet gotten to that point. How do we know that security researchers won't just move to testing things later as well?
  - enedil 4mo ago
    Because entire point of their work is to find the issues as fast as possible, and most importantly, before others.
    - saghm 4mo ago
      You have a lot more faith than I do that companies paying security researchers will not try to cut corners by directing the researchers they employ or hire to look at stuff that they aren't even about to install.
chillax 4mo ago
Companies such as socket and safedep will still scan new packages and alert on malware (if they are able to detect it) so the packages are taken down before they pass your cool down
- cluckindan 4mo ago
  It’s kind of insane this doesn’t happen in the publish pipeline by default.

darig 4mo ago

[dead]

QuiEgo 4mo ago

As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.

smrtinsert 4mo ago
There's literally no excuse - I'm still baffled.
- scorpioxy 4mo ago
  You mean there's no excuse for cooldowns? Yeah, there is. Security consultants have for years been saying that you need to always keep your dependencies updated. This is often parroted without any context of whether a package needs to be updated or not. And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here. I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
  - oasisbob 4mo ago
    I think the post you're replying to was commenting on "web dev is a culture shock in so many ways", not the concept of cooldowns overall.
schonfinkel 4mo ago
I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
- 4mo ago

k_sze 4mo ago

Nice work! Is there a sensible way to add a cooldown to Docker/Podman image pulling?

TacticalCoder 4mo ago

> Hope it's ok I hijack this thread again about setting up cooldowns... In addition to cooldowns it'd be nice if more package managers did triage between security fixes and normal releases (bug fix / performance improvement / new functionalities). It's totally possible to say: "A security fix must only be a security fix and cannot ship any other feature". Then, for a start, a security fix becomes easier to audit (both by security researchers and by the tools security researchers are using). And then a cooldown can be used for the regular releases (e.g. non security-related bug fixes, perfs improvements, new functionalities, etc.) but no cooldown (or a much smaller countdown) for security fixes. Something has to be said about a system like Debian where you can have an extremely stable server and you can configure unattended upgrades to only apply security fixes but nothing else. Such new package releases are easier to audit by security researchers.

collinmanderson 4mo ago
> no cooldown (or a much smaller countdown) for security fixes. A supply chain attack would likely able to publish a "security" release just as easily as a normal release, so I don't think that would help much.

naruhodo 4mo ago

> but if you have a loved one who just needs a one click fix, these can likely save them from the next attack. I'm not letting gam gams anywhere near that shit. She can continue writing her own apps in assembly language - it's good for her brain health!