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

101–110 of 135 posts

Re: Just say no to :latest

#101

Post by onedr0p »

jacobr wrote: post #43

People are mentioning that pinning versions lead to overhead in updates. These people have probably not used Renovate https://docs.renovatebot.com/ Renovate is smart enough to understand that a task such as “Update Node to v16” means updating .nvmrc files, updating FROM in Dockerfiles and engines in package.json in a single PR it creates for you.

Renovate is amazing, and a tool most Developer and DevOps engineers should learn. It's FOSS, and does a great job at dependency management across a very wide range of software like NPM, Terraform, Docker, Ansible, Maven, Golang, Rust and many others.

https://docs.renovatebot.com/modules/manager/

Re: Just say no to :latest

#102

Post by lamontcg »

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…

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 you probably want to confine these deployments to some sort of reasonable business hours).

Then the tech debt gets addressed automatically without any work. The work is all up front to write the tests that give you confidence about deployment to production, but that is work that needs to happens and pays off. You shouldn't need to have human testing in the loop.

Re: Just say no to :latest

#103

Post by crummy »

lamontcg wrote: post #102
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…

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.

Re: Just say no to :latest

#104

Post by charcircuit »

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.

Self hosting protects against attacks against the availability of your supply chain.

Re: Just say no to :latest

#105

Post by raybb »

lamontcg wrote: post #102
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…

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…

I haven't used it myself but I'm pretty sure Whitesource Renovate is free tool that tries to do just that.

https://www.whitesourcesoftware.com/free-developer-tools/ren...

Re: Just say no to :latest

#106

Post by solatic »

falcolas wrote: post #95
solatic wrote: post #48

Earlier quoted context omitted.

Of course it's not. But it's not King, either.

If you're fedramp certified, they kinda are. Fedramp is the key that unlocks a lot of really high-paying customers, and if you lose your certification those customers (with their firehose of revenue) go poof. How to lose certification: Don't address a known vulnerability (CVE) within a specific number of days, based on severity. Doesn't matter if it's log4j or some random executable in your images that's never used.…

FedRAMP also requires you to explicitly give veto power to InfoSec at every stage of design, development, implementation, operation, and maintenance, and to employ a Change Control Board (CM-03).

There's only ~250 companies / products that are Authorized at any level of FedRAMP, and many of them are explicitly "Federal" versions of their products in order to isolate the organizational controls away from affecting their commercial offerings.

Re: Just say no to :latest

#107

Post by humanrebar »

lamontcg wrote: post #102
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…

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…

Agreed. There are logical, version-flexible dependencies. And then there are rigid, version-specific dependencies.

Robust systems need to model both so they can support reproducibility and automation needs.

Re: Just say no to :latest

#108

Post by ziml77 »

thenerdhead wrote: post #62

The age old question is "How quickly do you update?" Too slow - Exposed to known vulnerabilities. Too fast - Susceptible to active supply chain attacks. There's tradeoffs, and there's no solution here. It's a hard problem.

Not just from a vulnerability poerspective but also a dev and testing perspective. Constant updates makes testing far more involved for every release since you can't just focus on the parts the dev work would have affected, you also need to thoroughly test everything that was calling into the updated dependency. But if you don't update enough, once you really do need to update either for security or feature reasons, you may have a nightmarish process ahead of you of dealing with breaking changes and transitive dependency incompatibilities.

Re: Just say no to :latest

#109

Post by tlarkworthy »

If you don't use latest, your ecosystem fragments and risks diamond dependencies. If you do use latest, some of your ecosystem risks randomly breaking.

I think it's best to use latest because the combinatorics of the ecosystem as a whole is much smaller. With everything on latest, you have to play whack-mole on individual services to get them to catch up. But you are doing this just when the community at large is most invested in understanding the process of upgrading.

The alternative is that ancient binary A depends on ancient binary B's legacy behaviour, and B has no need to upgrade but A have a very serious need and now you have a serious problem. Maybe upgrading B breaks C for instance. It's almost uncoordinateable at that point once versions drift significantly. You get true technical debt.

Re: Just say no to :latest

#110

Post by throwanem »

raybb wrote: post #105
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…

I haven't used it myself but I'm pretty sure Whitesource Renovate is free tool that tries to do just that. https://www.whitesourcesoftware.com/free-developer-tools/ren...

Weird, I thought it was a tool for encouraging engineers to learn how to use Github PR search filters.
Post reply on HN