5 ms·

I hate this. Delaying real bugfixes to achieve some nebulous poorly defined security benefit is just bad engineering.

wrs 11mo ago
Do you upgrade all your dependencies every day? If not, then there’s no real difference in upgrading as if it were 7 days ago.
- jerlam 11mo ago
  Your CI/CD might be setup to upgrade all your dependencies on every build.
  - wrs 11mo ago
    I’ve seen a lot of CI/CD setups and I’ve never seen that. If that were common practice, it would certainly simplify the package manager, since there would be no need for lockfiles!
    - jerlam 11mo ago
      I didn't necessarily say they were good CI/CD practices.
    - chuckadams 11mo ago
      I do see some CI running without lockfiles, and there's still a contingent that believes that libraries should never commit their lockfiles. It's a reasonably good idea to _test_ a configuration without the lockfile, since any user of your dependency is using _their_ lockfile that their local solver came up with, not yours, but this ought to be something you'd do alongside the tests using the lockfile. So locking down the CI environment is a good idea for that and many other reasons. Realistically, no one does full side-by-side tests with and without lockfiles, but it's a good idea to at least do a smoke test or two that way.
- ktpsns 11mo ago
  Unattended upgrades for server installations are very common. For instance, for Ubuntu/Debian this updates by default daily (source: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/ https://documentation.ubuntu.com/server/how-to/software/auto...). No cooldown implemented, AFAIK. Of course we talk about OS security upgrades here, not library dependencies. But the attack vector is similar.
- jcalvinowens 11mo ago
  I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs since.
  - smaudet 11mo ago
    > zero day is going to bite you in the ass Maybe your codebase is truly filled with code that is that riddled with flaws, but: 1) If so, updating will not save you from zero days, only from whatever bugs the developers have found. 2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them. 3) In the case where a real issue is found, I can't imagine it isn't hard to use the aforementioned security vendors, and use their recommendations to force updates outside of a cooldown period.
    - jcalvinowens 11mo ago
      My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :)
      - smaudet 11mo ago
        If you mean operating system code, that is generally opaque, and not quite what the article is talking about (you don't use a dependency manager to install code that you have reviewed to perform operating system updates - you can, and that is fantastic for you, but not I imagine what you mean). Although, even for Operating Systems, cooldown periods on patches are not only a good thing, but something that e.g. a large org that can't afford downtime will employ (managing windows or linux software patches, e.g.). The reasoning is the same - updates have just as much chance to introduce bugs as fix them, and although you hope your OS vendor does adequate testing, especially in the case where you cannot audit their code, you have to wait so that either some 3rd party security vendor can assess system safety, or you are able to perform adequate testing yourself.
- midasz 11mo ago
  Renovate (dependabot equiv I think) creates PRs, I usually walk through them every morning or when there's a bit of downtime. Playing with the idea to automerge patches and maybe even minor updates but up until now it's not that hard to keep up.
swatcoder 11mo ago
The point is to apply a cooldown to your "dumb" and unaccountable automation, not to your own professional judgment as an engineer. If there's a bugfix or security patch that applies to how your application uses the dependency, then you review the changes, manually update your version if you feel comfortable with those changes, and accept responsibility for the intervention if it turns out you made a mistake and rushed in some malicious code. Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them, and so don't need to be rushed in. And most others are "fixes" for issues that were apparently not presenting an eminent test failure or support crisis for your users and don't warrant being rushed in. There's not really a downside here, for any software that's actually being actively maintained by a responsible engineer.
- jcalvinowens 11mo ago
  You're not thinking about the system dependencies. > Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them Sorry, this is really ignorant. You don't appreciate how much churn their is in things like the kernel and glibc, even in stable branches.
  - swatcoder 11mo ago
    > You're not thinking about the system dependencies. You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed. If there's a zero day vulnerability that affects your system, which is a rare but real thing, you can be notified and bypass a cooldown system. Otherwise, you've presumably either adapted your workflow to work around a bug or you never even recognized one was there. Either way, waiting an extra <cooldown> before applying a fix isn't going to harm you, but it will dampen the much more dramatic risk of instability and supply chain vulnerabilities associated with being on the bleeding edge.
    - jcalvinowens 11mo ago

wrs 11mo ago

Do you upgrade all your dependencies every day? If not, then there’s no real difference in upgrading as if it were 7 days ago.

jerlam 11mo ago
Your CI/CD might be setup to upgrade all your dependencies on every build.
- wrs 11mo ago
  I’ve seen a lot of CI/CD setups and I’ve never seen that. If that were common practice, it would certainly simplify the package manager, since there would be no need for lockfiles!
  - jerlam 11mo ago
    I didn't necessarily say they were good CI/CD practices.
  - chuckadams 11mo ago
    I do see some CI running without lockfiles, and there's still a contingent that believes that libraries should never commit their lockfiles. It's a reasonably good idea to _test_ a configuration without the lockfile, since any user of your dependency is using _their_ lockfile that their local solver came up with, not yours, but this ought to be something you'd do alongside the tests using the lockfile. So locking down the CI environment is a good idea for that and many other reasons. Realistically, no one does full side-by-side tests with and without lockfiles, but it's a good idea to at least do a smoke test or two that way.
ktpsns 11mo ago
Unattended upgrades for server installations are very common. For instance, for Ubuntu/Debian this updates by default daily (source: https://documentation.ubuntu.com/server/how-to/software/automatic-updates/ https://documentation.ubuntu.com/server/how-to/software/auto...). No cooldown implemented, AFAIK. Of course we talk about OS security upgrades here, not library dependencies. But the attack vector is similar.
jcalvinowens 11mo ago
I upgrade all dependencies every time I deploy anything. If you don't, a zero day is going to bite you in the ass: that's the world we now live in. If upgrading like that scares you, your automated testing isn't good enough. On average, the most bug free Linux experience is to run the latest version of everything. I wasted much more time backporting bugfixes before I started doing that, than I have spent on new bugs since.
- smaudet 11mo ago
  > zero day is going to bite you in the ass Maybe your codebase is truly filled with code that is that riddled with flaws, but: 1) If so, updating will not save you from zero days, only from whatever bugs the developers have found. 2) Most updates are not zero day patches. They are as likely to (unintentionally) introduce zero days as they are to patch them. 3) In the case where a real issue is found, I can't imagine it isn't hard to use the aforementioned security vendors, and use their recommendations to force updates outside of a cooldown period.
  - jcalvinowens 11mo ago
    My codebase runs on top of the same millions of lines of decades old system code that yours does. You don't seem to appreciate that :)
    - smaudet 11mo ago
      If you mean operating system code, that is generally opaque, and not quite what the article is talking about (you don't use a dependency manager to install code that you have reviewed to perform operating system updates - you can, and that is fantastic for you, but not I imagine what you mean). Although, even for Operating Systems, cooldown periods on patches are not only a good thing, but something that e.g. a large org that can't afford downtime will employ (managing windows or linux software patches, e.g.). The reasoning is the same - updates have just as much chance to introduce bugs as fix them, and although you hope your OS vendor does adequate testing, especially in the case where you cannot audit their code, you have to wait so that either some 3rd party security vendor can assess system safety, or you are able to perform adequate testing yourself.
midasz 11mo ago
Renovate (dependabot equiv I think) creates PRs, I usually walk through them every morning or when there's a bit of downtime. Playing with the idea to automerge patches and maybe even minor updates but up until now it's not that hard to keep up.

swatcoder 11mo ago

The point is to apply a cooldown to your "dumb" and unaccountable automation, not to your own professional judgment as an engineer. If there's a bugfix or security patch that applies to how your application uses the dependency, then you review the changes, manually update your version if you feel comfortable with those changes, and accept responsibility for the intervention if it turns out you made a mistake and rushed in some malicious code. Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them, and so don't need to be rushed in. And most others are "fixes" for issues that were apparently not presenting an eminent test failure or support crisis for your users and don't warrant being rushed in. There's not really a downside here, for any software that's actually being actively maintained by a responsible engineer.

jcalvinowens 11mo ago
You're not thinking about the system dependencies. > Meanwhile, most of the time, most changes pushed to dependencies are not even in the execution path of any given application that integration with them Sorry, this is really ignorant. You don't appreciate how much churn their is in things like the kernel and glibc, even in stable branches.
- swatcoder 11mo ago
  > You're not thinking about the system dependencies. You're correct, because it's completely neurotic to worry about phantom bugs that have no actual presence of mind but must absolutely positively be resolved as soon as a candidate fix has been pushed. If there's a zero day vulnerability that affects your system, which is a rare but real thing, you can be notified and bypass a cooldown system. Otherwise, you've presumably either adapted your workflow to work around a bug or you never even recognized one was there. Either way, waiting an extra <cooldown> before applying a fix isn't going to harm you, but it will dampen the much more dramatic risk of instability and supply chain vulnerabilities associated with being on the bleeding edge.
  - jcalvinowens 11mo ago