Ask HN: Benefits to Keeping Packages Updated? | Hacker News Reader

Ask HN: Benefits to Keeping Packages Updated?

6 pointsGuid_NewGuid7 comments

In light of the Moq issue yesterday[0] I'm interested to understand why the consensus seems to be so in favor of keeping packages up-to-date in software.

The common explanation I see is it "keeps you up to date with security and bug fixes".

But in practice this seems to just involve most orgs mandating Dependabot and mindlessly updating every dependency when a new version becomes available. (Yes in an ideal world you code review every change in every dependency, but... I mean, let's be real here. Just take the update frequency of the AWS SDK packages in isolation, very few orgs are actually doing this)

As a maintainer of an open source library I know most releases are a crapshoot, they're just as likely to contain new bugs and flaws as they are to fix old ones.

So staying up-to-date seems to open up codebases to far greater risks than outdated dependencies:

1) Zero days, a new package launches with some critical security flaw that isn't going to get noticed for some time.

2) Supply chain attacks, old packages are generally immutable. Therefore most supply chains attacks seem to involve take-overs of existing package (name)s by disgruntled or new hostile 'maintainers'. The new versions are far more at risk.

3) New bugs, the dirty truth of OSS is most work is done by unpaid people with little time or ability to focus. Most software isn't formally verified. New updates are a risk.

In addition the old version is a known quantity. Unless you know absolutely the version you are running is compromised (log4j, OpenSSL) what benefits does updating actually bring? The default presumption that version number goes up is better seems like yet more security/compliance cargo cult behavior.

What am I missing here?

[0] https://github.com/moq/moq/issues/1374

I'm not a fan of blindly updating; I'd rather read the changelogs and decide if I need to update or not, but I sort of understand the utility of it. Most testing happens against the latest release version or HEAD in version control. If the version you're running has different behavior than those two versions and the change wasn't well documented, and the behavior in your version is problematic, it's not likely that other people will discuss it and call your attention to it. Even if people run into that bug, they may just update and move on, rather than post about it being broken.

Depending on the project, and the changes involved, sometimes it's beneficial to upgrade frequently and make required integration changes in small increments rather than say once a year with a big change. Sometimes, it's much worse to follow the changes; some projects churn a lot and integration changes are kind of fixed per release, letting releases pile up means less overall work in that case.

Also, if you get support from upstream (which IMHO is a big if), they'll tend to prefer for you to be working on a current version. You tend not to get much support when you're running older versions. OTOH, I'm not used to having a support workflow. It's often too hard to engage with external developers, so either the external software works, or you make changes so it works, without discussing with upstream.

In my experience, keeping packages up-to-date is a great idea but really hard to do without adding ton of overhead, especially in the cloud space. As for the argument of security, it's mostly legal. Security teams can basically said, we keep our system up-to-date, there isn't much we can do about it. This will pass muster in court, the board and general public.

In cloud space, every team and numb nuts spin up endless EC2s, pip/node/apt-get install god-knows-what packages from god-knows-who developer(s) and build applications off that. No wonder security audit and keeping systems updated have become a nightmare.

Back in the days when we keep our servers like pets, we can easily update and manage them because we squeeze out max performance, and carefully select packages that are applicable to all apps. It's a wonder we could get anything done fast enough.

If you don't keep your software update you end up trying to write AVX2 instructions on systems in which the debuggers or analysis tools don't understand them. Or the same but newer with AVX512.

Unfortunately updating also means you get people like Debian which patch bugs into the software they distribute; which isn't really updated. The SSL or SSH key bug from something like 10 years ago and the memory leak in Transmission much more recently.

I am certainly for never updating when you think you have a working system. I am experienced regret after updating my desktop the time I managed 100+ days of uptime. So many pieces of software are worse since.

I think there is and should be a middle ground between "cutting edge" and "never update".

You should certainly lock semvar versions (I don't mean lock to major, I mean 100% lock to a specific version) but you should routinely audit and update. I've worked on both ends and they are honestly both terrible. If you don't update fast enough, you build up kludge where it becomes difficult to get onto LTS. If you update too fast, you are constantly putting out fires with everything being in scope as a possible problem.

I think every 6 months is fast enough without having it be breaking changes. It gives the version time to mature while you continue working on features. It's a lot easier to work off a stable platform where most of the time you can ignore pre-existing dependencies having breaking issues.

In software engineering, the goal is to solve problems not create them and I think a lot of engineers, especially the more junior, have their head too far into "must have best-i-est system evur w/ latest features" rather than "stable platform to solve problems from".

Automatically keeping packages up-to-date used to be good advice, but now the ROI for exploiting automatically-updated libraries is high enough that I don't think it's true anymore.

This is more true once you factor in the non-security-related problems with not pinning your dependencies (e.g. when the Cryptography library in PyPI decided to introduce a Rust dependency and broke many people's builds as a result)

I've settled for the middle ground of

- pinning all dependencies

- using something like Snyk to monitor for vulnerabilities in dependencies.

- manually updating dependencies that are known to be vulnerable

Zero-day exploits can occur for any version of a software component or application. Staying on old versions is definitely not a protection against those exploits.

The solution is distributed code review:

https://github.com/crev-dev/

Reply on news.ycombinator.com