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

Just say no to :latest

platformers.dev

Post reply on HN
Print view View original

121–130 of 135 posts

Re: Just say no to :latest

#121

Post by PeterisP »

cogman10 wrote: post #120
88913527 wrote: post #88

Earlier quoted context omitted.

Needlessly upgrading all of your packages leaves you open to supply chain attacks. If one of those NPM packages got quietly compromised (and my lockfile likely has 4-to-5 digits worth of dependencies in it), you invested time in making what amounts to an unneeded change to expose yourself.

Any bit of software can have a very nasty vulnerability (looking at you, log4j). Leaving your software pinned to old versions exposes you to existing undiscovered CVEs. This is a pick your poison circumstance.

In general, for undiscovered CVEs new versions will be as exposed as old versions - if the bug was not discovered, it was not fixed as well; and if the latest version fixes an exploitable security flaw then there generally will be a CVE issued along with that release. Using the same log4j as an example, all the (many!) projects which were still using the old 1.x log4j branch were not exposed, but those who were using the latest released version were exposed to the undiscovered CVE at the moment it was released.

IMHO a reasonable compromise is to watch for discovered CVEs and update your dependencies when appropriate, but keep them pinned if no known CVEs apply.

Re: Just say no to :latest

#122

Post by PeterisP »

cuteboy19 wrote: post #61
EdwardDiego wrote: post #37

Earlier quoted context omitted.

I've used Maven version ranges to great effect... ...only projects that actually observe semver. (Jackson, take a bow for doing so with your patch releases. I wouldn't use it for your 'minor' releases though.)

Maven versions are not present in VCS if you use ranges. Wouldn't this cause issues like not know what Library version is being used in production and builds not being reproducible?

You can solve that issue not at the source/VCS level but with artifact management, properly logging, storing and documenting the things that were built from that source. In some places that's tightly integrated with VCS in a single pipeline, in others the source and built artifacts are managed quite separately, especially if you're packaging many different builds for different customers.

Re: Just say no to :latest

#123

Post by nextaccountic »

raffraffraff wrote: post #82

I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. Or I pin to arbitrary versions that happened to be latest when pip/npm/terraform first created the precious word-of-god lock file, leaving future engineers afraid to upgrade those packages because "Chesterton's Fence". Pinning ver…

> For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything.

This security scan would be absurd. The amount of churn of updating everything the day it is released would be insane, specially wrt. breaking changes.

Re: Just say no to :latest

#124

Post by karmelapple »

raffraffraff wrote: post #82

I somewhat agree. But it's not that simple in practice. For example, I pin every single version and the container fails a security scan because it's not using latest versions of everything. Or I pin to arbitrary versions that happened to be latest when pip/npm/terraform first created the precious word-of-god lock file, leaving future engineers afraid to upgrade those packages because "Chesterton's Fence". Pinning ver…

Dependabot is great for this. We have everything pinned, but dependabot takes care of a bunch of manual steps to upgrade a dependency: it updates package.json, package-lock.json, pulls release notes for all the changes since your pinned version, and makes a PR and triggers your CI build.

We’ve found many broken builds thanks to this, and could then create an issue in our tracker to tackle that tech debt later.

If the build doesn’t break, we review the new version’s release notes, and sometimes even look at the code changes of the open source package. Overall it’s helped us keep more up to date, has made upgrading versions of Node less painful, and even helped us adopt some improvements sooner than we otherwise would have.

Re: Just say no to :latest

#125

Post by delusional »

crummy wrote: post #103
lamontcg wrote: post #102

Earlier quoted context omitted.

You need to have a CD system which takes equality pinned deps and bumps them when new versions come through and automatically runs the new versions through whatever your test/integration/production environments looks like. And you should have sufficient integration testing that you should have confidence that an automated process should be able to decide if the new version should get deployed to prod (being realistic…

Do people have automated tests to validate their SMSs are sent correctly (and received by a real phone)? Or that credit card payments are made correctly? These are things I use third party libraries for, and what I worry might break when I upgrade dependency versions.

I guess the question becomes how far out you want to test. If your credit card processor is a third party they could technically break something, regardless of which version of their library you use. In that case, do you really care that a transaction goes through, or do you just care that you used your third parties interface correctly (be that rest or binary api calls).

If your requirements aren't that sharp, like maybe you can take a day or two to process the credit card payments, you could get away with monitoring your application and configuring alarms for if no transactions go through. That way you'd catch errors originating from your third party as well.

Re: Just say no to :latest

#126

Post by delusional »

88913527 wrote: post #118
raffraffraff wrote: post #113

Earlier quoted context omitted.

Ok, so let's say it's day one: how do you choose all of your initial pinned versions? How do you know they're safe? What if you luck-out in the supply chain attack lottery and pin malware?

Older packages are more likely to be vetted as non-problematic than newer packages. As time goes own, the vulnerabilities are disclosed. If you're upgrading to a package that's 1 day old, the community hasn't had the time to go through that process and disseminate the vulnerability. Your point is valid, but I think it's an increased risk since time is against you when you accept fresher, newer, unproven versions of y…

I think you're right that cutting edge carries the risk of introducing new vulnerabilities that haven't been observed yet. And the closer you are to release, the less time the security community has had to look into it.

Conversely, there's also a factor that says that after some time, the security community will stop looking at a specific version. Even if that version still has vulnerabilities.

Those two factors lead me to believe there's some sort of sweet spot. You probably don't want the cutting edge newest version, but you still want a version new enough that it's in widespread use.

Re: Just say no to :latest

#127

Post by delusional »

roblabla wrote: post #96
duped wrote: post #91

Earlier quoted context omitted.

The only real defense to supply chain attacks are audits and self hosted dependencies/packages.

> self hosted dependencies/packages. Why? If your lockfile specifies and enforces the hash of the package, you don't need to self-host it - the lockfile will take care of detecting supply chain compromises that swaps a package with another. 100% agree on audits being necessary.

You're still downloading random stuff from the internet. A vulnerability in your package manager could let an attacker bypass the hash check, or they could discover a hash collision.

If you really want to be sure, having the exact bits on a system you control seems like the right move.

Re: Just say no to :latest

#128

Post by keymone »

zufallsheld wrote: post #71
keymone wrote: post #5

Earlier quoted context omitted.

yeah, well, i stopped reading when i saw that "GOOD" example. it's not. and that isn't a "side point", that's the most critical point for preserving security and reproducibility of builds.

Well then you'd vendor your docker images anyway and not pull them from the internet, right?

Sure, and many do that, but you don't have to if you refer by digest of image's contents.

Re: Just say no to :latest

#129

Post by jen20 »

izacus wrote: post #92
solatic wrote: post #35

Forget for a second the security concerns - If you lose :latest, and the build breaks, you need to spend unexpected time fixing the build, for whatever reason that :latest broke it, in order to continue with the business objective that you were actually tasked to do. Essentially, you have InfoSec muscling in and demanding, by the most coercive way possible, that Thou Shalt Not Do Your Job Without Bowing Before Me. Wh…

This! It gets even better - there WILL be a time at your company when you'll need to revert for whatever reason. That reason will most likely be something VeryImportant(tm) and will probably have to be done RightNow(tm) on weekend if you're unlucky. At that time, you REALLY don't want to find out that you forgot to pin your dependencies and that your older build now doesn't run due to breaking changes and you have no…

> you have no frigging idea what versions of that random NPM crap library were you running 5 weeks ago.

The most telling part of this screed is that you don’t appear to know you can tell exactly what version you were using at any version-controlled point in time by looking at the lock file for NPM.

Re: Just say no to :latest

#130

Post by isbvhodnvemrwvn »

EdwardDiego wrote: post #115
isbvhodnvemrwvn wrote: post #90

Earlier quoted context omitted.

Not to mention that Maven doesn't have any mechanism for locking in transitive versions, because typically everyone uses hardcoded patch versions and never update them.

How do you mean? You can override versions of transitive dependencies.

In most projects JVM devs don't pin the versions of transitive dependencies, even though in many other languages it's recognized as a basic functionality of the build tool.
Post reply on HN