Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should all be using dependency cooldowns

blog.yossarian.net

Post reply on HN
Print view View original

201–210 of 287 posts

Re: We should all be using dependency cooldowns

#201

Post by teddyh »

dap wrote: post #86
embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

You can choose to either live at the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, as discussed here: https://news.ycombinator.com/item?id=21785399>

Re: We should all be using dependency cooldowns

#202

Post by cxr »

lijok wrote: post #177
cxr wrote: post #34

What everyone should all be doing is practicing the decades-old discipline of source control. Attacks of the form described in the post, where a known-good, uncompromised dependency is compromised at the "supply chain" level, can be 100% mitigated—not fractionally or probabilistically—by cutting out the vulnerable supply chain. The fact that people are still dragging their feet on this and resist basic source control…

Vendoring hasn’t been feasible since CI became free for OSS. You cannot vendor yourself out of a nuclear waste pile that is the modern OSS ecosystem.

Not sure what any of what you wrote has to do with the subject at hand. Your comments are vague and come across as non-sequiturs at best.

The only thing I've claimed is that keeping dependencies under source control neutralizes the supply chain attacks that the author of the post describes.

They each belong to two totally different genres of comment.

If you have something concrete to say about the relationship between supply chain attacks and dependencies being excluded from source control in lieu of late-fetching them right at/before build time, then go for it.

Re: We should all be using dependency cooldowns

#203

Post by icehawk »

jcalvinowens wrote: post #53
icehawk wrote: post #51

Earlier quoted context omitted.

> 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. I think you're using a different definition of zero day than what is standard. Any zero day vulnerability is not going to have a patch you can get with an update.

Zero days often get fixed sooner than seven days. If you wait seven days, you're pointlessly vulnerable.

Known vulnerabilities often get fixed sooner than seven days.

You will not know how long it takes to get a zero day fixed, because zero in "zero day" ends when the vendor is informed:

> "A zero day vulnerability refers to an exploitable bug in software that is unknown to the vendor."

Re: We should all be using dependency cooldowns

#205

Post by [deleted] »

mirashii wrote: post #61
hypeatei wrote: post #52

Earlier quoted context omitted.

> Sadly, not enough tooling seems to take this into account Most tooling (e.g. Dependabot) allows you to set an interval between version checks. What more could be done on that front exactly? Devs can already choose to check less frequently.

The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.

[deleted]

Re: We should all be using dependency cooldowns

#206

Post by cncjchsue7 »

dap wrote: post #86
embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

This is why I don't use dependencies that break backwards compatibility.

If you break my code I'm not wasting time fixing what you broke, I'm fixing the root cause of the bug: finding your replacement.

Re: We should all be using dependency cooldowns

#207

Post by xp84 »

dap wrote: post #86
embedding-shape wrote: post #46

Earlier quoted context omitted.

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if a…

At my last job, we only updated dependencies when there was a compelling reason. It was awful. What would happen from time to time was that an important reason did come up, but the team was now many releases behind. Whoever was unlucky enough to sign up for the project that needed the updated dependency now had to do all those updates of the dependency, including figuring out how they affected a bunch of software tha…

OP wisely said for critical vulnerabilities is where the actual exposure needs to be assessed, in order to make an exception from a rule like “install the latest release of things that’s been published for X length of time.”

For instance if you use a package that provides a calendar widget and your app uses only the “western” calendar and there is a critical vulnerability that only manifests in the Islamic calendar, you have zero reason to worry about an exploit.

I see this as a reasonable stance.

Re: We should all be using dependency cooldowns

#208

Post by zahlman »

skydhash wrote: post #117
xmodem wrote: post #95

Earlier quoted context omitted.

I've seen this argument made frequently. It's clearly a popular sentiment, but I can't help feel that it's one of those things that sounds nice in theory if you don't think about it too hard. (Also, cards on the table, I personally really like being able to pull in a tried-and-tested implementation of code to solve a common problem that's also used by in some cases literally millions of other projects. I dislike havi…

Anything that pulled in chalk. You need a very good reason to emit escape sequences. The whole npm (and rust, python,..) ecosystem assumes that if it’s a tty, then it’s a full blown xterm-256color terminal. And then you need to pipe to cat or less to have sensible output. So if you’re adding chalk, that generally means you don’t know jack about terminals.

In the Python world, people often enough use Rich so that they can put codes like [red] into a string that are translated into the corresponding ANSI. The end user pays several megabytes for this by default, as Rich will also pull in Pygments, which is basically a collection of lexers for various programming languages to enable syntax highlighting. They also pay for a rather large database of emoji names, a Markdown parser, logic for table generation and column formatting etc. all of which might go unused by someone who just doesn't want to remember \e[31m (or re-create the lookup table and substitution code).

Re: We should all be using dependency cooldowns

#209

Post by zahlman »

swatcoder wrote: post #14
jayd16 wrote: post #3

Doesn't this mean you're leaving yourself open to known vulnerabilities during that "cool down" time?

No. A sane "cooldown" is just for automated version updates relying on semantic versioning rules, which is a pretty questionable practice in the first place, but is indeed made a lot more safe this way. You can still manually update your dependency versions when you learn that your code is exposed to some vulnerability that's purportedly been fixed. It's no different than manually updating your dependency version whe…

> A sane "cooldown" is just for automated version updates relying on semantic versioning rules, which is a pretty questionable practice in the first place, but is indeed made a lot more safe this way.

I'm reminded of how new Setuptools versions are able to cause problems for so many people, basically because install tools default to setting up isolated build environments using the latest version of whatever compatible build backend is specified (which in turn defaults to "any version of Setuptools"). qv. my LWN article https://lwn.net/Articles/1020576/ .

Re: We should all be using dependency cooldowns

#210

Post by mik3y »

woodruffw wrote: post #92
compumike wrote: post #85

There's a tradeoff and the assumption here (which I think is solid) is that there's more benefit from avoiding a supply chain attack by blindly (by default) using a dependency cooldown vs. avoiding a zero-day by blindly (by default) staying on the bleeding edge of new releases. It's comparing the likelihood of an update introducing a new vulnerability to the likelihood of it fixing a vulnerability. While the article…

Yep, that's definitely the assumption. However, I think it's also worth noting that zero-days, once disclosed, do typically receive advisories. Those advisories then (at least in Dependabot) bypass any cooldown controls, since the thinking is that a known vulnerability is more important to remediate than the open-ended risk of a compromised update. > I'm sure the majority of bugs and vulnerabilities were never supply…

Could a supply chain attacker simulate an advisory-remediating release somehow, i.e., abuse this feature to bypass cooldowns?
Post reply on HN