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

111–120 of 287 posts

Re: We should all be using dependency cooldowns

#111

Post by xmodem »

buu700 wrote: post #99
xmodem wrote: post #98

Earlier quoted context omitted.

Let's have AI generate the same vulnerable code across hundreds of projects, most of which will remain vulnerable forever, instead of having those projects all depend on a central copy of that code that can be fixed and distributed once the issue gets discovered. Great plan!

You're attacking a straw man. No one said not to use dependencies.

At one stage in my career the startup I was working at was being acquired, and I was conscripted into the due-diligence effort. An external auditor had run a scanning tool over all of our repos and the team I was on was tasked with going through thousands of snippets across ~100 services and doing something about them.

In many cases I was able to replace 10s of lines of code with a single function call to a dependency the project already had. In very few cases did I have to add a new dependency.

But directly relevant to this discussion is the story of the most copied code snippet on stack overflow of all time [1]. Turns out, it was buggy. And we had more than once copy of it. If it hadn't been for the due diligence effort I'm 100% certain they would still be there.

[1]: https://news.ycombinator.com/item?id=37674139

Re: We should all be using dependency cooldowns

#112

Post by testplzignore »

nicoburns wrote: post #43

I would like to see a variant of this that is based on a manual review/audit process rather than a time-based cooldown. Something like, upgrade once there are N independent positive reviews AND less than M negative reviews (where you can configure which people are organisations you trust to audit). And of course you would be able to audit dependencies yourself (and make your review available for others).

I've been wanting something like this for years. It's simply impossible for millions of companies to individually review the thousands of updates made to their thousands of dependencies every day.

Imagine a world where every software update has hundreds of signoffs from companies across the industry. That is achievable if we work together. For only a few minutes a day, you too can save a CVSS 10.0 vulnerability from going unpatched :)

Re: We should all be using dependency cooldowns

#113

Post by cmckn »

I don’t think it’s bad advice, it really just depends on the project, its dependencies, and your attack surface. I so badly want this era of mindlessly ticking boxes to end. Security is a contact sport! “Best practices” won’t get you to the promised land, you have to actually think critically about the details day to day.

Re: We should all be using dependency cooldowns

#114

Post by o11c »

embedding-shape wrote: post #49
gr4vityWall wrote: post #23

The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wro…

> For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects Web search shows some: https://packages.debian.org/search?keywords=node&searchon=na... (but also shows "for optimizing reasons some results might have been suppressed" so might not be all) Although probably different from other distros, Arch for example seems to have none.

Locally, you can do:

  apt-cache showpkg 'node-*' | grep ^Package:
which returns 4155 results, though 727 of them are type packages.

Using these in commonjs code is trivial; they are automatically found by `require`. Unfortunately, system-installed packages are yet another casualty of the ESM transition ... there are ways to make it work but it's not automatic like it used to be.

Re: We should all be using dependency cooldowns

#116

Post by woodruffw »

abalone wrote: post #115

Sure, but there's an obvious tradeoff: You're also delaying the uptake of fixes for zero-day vulnerabilities. The article does not discuss this tradeoff.

The article assumes that engineers have the technical wherewithal to know when they should manually upgrade their dependencies!

Clearly I should have mentioned that Dependabot (and probably others) don't consider cooldown when suggesting security upgrades. That's documented here[1].

[1]: https://docs.github.com/en/code-security/dependabot/working-...

Re: We should all be using dependency cooldowns

#117

Post by skydhash »

xmodem wrote: post #95
cosmic_cheese wrote: post #22

I think there’s a much stronger argument for policies that both limit the number and complexity of dependencies. Don’t add it unless it’s highly focused (no “everything libraries” that pull in entire universes of their own) and carries a high level of value. A project’s entire dependency tree should be small and clean. Libraries themselves should perhaps also take a page from the book of Linux distributions and offer…

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.

Re: We should all be using dependency cooldowns

#118

Post by awesome_dude »

abalone wrote: post #115

Sure, but there's an obvious tradeoff: You're also delaying the uptake of fixes for zero-day vulnerabilities. The article does not discuss this tradeoff.

Ye Olde "Cache Invalidation" problems really

Instead of updating the cache of dependencies you have immediately, the suggestion is to use the cooldown to wait....

As you point out, this means that you have a stale cache member has a critical fix applied.

Next week's solution - have a dependency management tool that alerts you when critical fixes are created upstream for dependencies you have

Followed by - now the zero day authors are publishing their stuff as critical fixes...

Hilarity ensues

Re: We should all be using dependency cooldowns

#119

Post by noosphr »

gr4vityWall wrote: post #23

The Debian stable model of having a distro handle common dependencies with a full system upgrade every few years looks more and more sane as years pass. It's a shame some ecosystems move waaay too fast, or don't have a good story for having distro-specific packages. For example, I don't think there are Node.js libraries packaged for Debian that allow you to install them from apt and use it in projects. I might be wro…

Never mistake motion for action.

An eco system moving too quickly, when it isn't being fundamentally changed, isn't a sign of a healthy ecosystem, but of a pathological one.

No one can think that js has progressed substantially in the last three years, yet trying to build any project three years old without updates is so hard a rewrite is a reasonable solution.

Re: We should all be using dependency cooldowns

#120

Post by jimbob45 »

Isn't this more or less what the Microsoft Long-Term Support (LTS) versus Short-Term Support (STS) is meant to do? LTS only receives critical updates but eschews all experimental/beta features. STS gets everything for the people that couldn't care less if their app gets hacked (e.g. apps like calculators, sandboxed internal tools, etc).

I know Ubuntu and others do the same but I don't know what they call their STS equivalent.

Post reply on HN