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

61–70 of 135 posts

Re: Just say no to :latest

#61

Post by cuteboy19 »

EdwardDiego wrote: post #37
oxfordmale wrote: post #9

This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince…

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?

Re: Just say no to :latest

#62

Post by thenerdhead »

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.

Re: Just say no to :latest

#63

Post by oxfordmale »

laumars wrote: post #23
oxfordmale wrote: post #13

Earlier quoted context omitted.

Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. It is always a trade off, however it is far more likely that a hacker will use a ten year old well exploited CVE, rather than a recent one

> Ideally you only use Docker official images,or their equivalent to avoid using unvetted code. Docker images don’t ship every dependency in the average development project. They’re also not a security guarantee either. > It is always a trade off, however it is far more likely that a hacker will use a ten year old well exploited CVE, rather than a recent one In general that’s the case but in practice that’s still the…

I have seen many cases where a something is pinned to a minor version, and then gets forgotten about for 2 or 3 years. In my current companies there is Production codebase that hasn't been touched for over two years. The original developers have long since moved on and no one really owns the code. That is the most common scenario leading to security breaches.

This is about succession planning, with the realisation there might not be any succession if business priorities change.

Re: Just say no to :latest

#64

Post by cesnja »

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 great, far better than relying on somebody remembering to upgrade dependencies in 12 different places.

But if you want full coverage, there will be a need to write a few regex managers. And testing can only be done in production on the mainline branch. The best way I found to do that was forking the repo to configure and try out renovate separately.

Re: Just say no to :latest

#65

Post by oxfordmale »

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…

My default workflow is not to the pin the version. The build will only break occasionally and is often trivial to fix. In the rare case it does require significant amount of work, and management is breathing down your neck, you do temporarily pin the version to get out the release, and create a backlog ticket to resolve this as soon as possible.

This workflow ensures any work for minor version upgrade is part of the development workflow. PMs can't deprioritise this work against more exciting shiny product features. If you include this as separate development tickets, it just tends to get deprioritised until it becomes a big chunk of work.

Re: Just say no to :latest

#66

Post by jayzalowitz »

Speaking as potentially one of the most prolific editors in tech history, your wife was right for the wrong reason.

You needed your article to state an example where latest dependency would kill a puppy.

Then your title is valid.

Re: Just say no to :latest

#67

Post by bombcar »

With a bit of work you can run with pinned versions that act like :latest - in the equivalent gradle scripts we have explicit dependencies but we have another script that updates them to whatever is actually the latest at the time.

So it’s like master-SNAPSHOT when we need it to be, but still with reproducibility and regular updates.

Re: Just say no to :latest

#68

Post by isbvhodnvemrwvn »

fuzzy2 wrote: post #50
isbvhodnvemrwvn wrote: post #12

Earlier quoted context omitted.

By convention npm packages are not deleted or hijacked.

You do realize that NPM package versions already are immutable? Dunno since when though. Deletion is possible within limits but it also is with Docker. All the hashes in the world won't bring back a deleted image.

They were made immutable after the issue was already widespread. Which is also why I'd heavily encourage to use hashes to pin container versions, even though people might not see the immediate need to do so.

Re: Just say no to :latest

#69

Post by chomp »

paskozdilar wrote: post #47
oefrha wrote: post #29

Earlier quoted context omitted.

This is very bad advice. Lots of nontrivial things aren't automatically compatible with the latest Python minor version. PyTorch for instance doesn't support Python 3.10 and it's been five months since the stable release (ten months since the first beta). For anything nontrivial, you almost always want to specify a minor Python version.

Why is this bad advice? The PyTorch scenario is an exception, not the rule, and the users of PyTorch should know not to use unsupported versions. > For anything nontrivial, you almost always want to specify a minor Python version. Depends on how you define "trivial".

It’s non-optimal advice because PyTorch is not the only library that runs into problems like this, because Python does not follow semver. You should pin to an X.Y release, and let .Z releases update automatically (which is where your security updates fall)

Re: Just say no to :latest

#70

Post by pojzon »

oxfordmale wrote: post #9

This is always a balance. The moment you pin to a specific version you need to have a process in place to ensure you regularly upgrade to avoid introducing vulnerabilities in your production system. Throughout my career I have seen many cases where certain software still runs on ancient versions as the team originally maintaining it is no longer around (e.g. reorganisations or lay-offs). It is always hard to convince…

Its hard to convince management that them adapting devops means they actually have to follow devops principles.

Too many times Ive seen companies throwing this buzzword around without understanding how much work is actually required to have real devops.

Post reply on HN