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

131–135 of 135 posts

Re: Just say no to :latest

#131

Post by laumars »

oxfordmale wrote: post #63
laumars wrote: post #23

Earlier quoted context omitted.

> 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 th…

I’ve seen many cases were version pinning has caused issues at the worst possible time (like missed delivery dates because of a breaking change in dependencies being pushed by maintainers at an inconvenient time for us).

Ultimately there’s no perfect answer here but given a choice I’d rather opt for a known risk than an unknown one.

Re: Just say no to :latest

#132

Post by EdwardDiego »

isbvhodnvemrwvn wrote: post #130
EdwardDiego wrote: post #115

Earlier quoted context omitted.

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.

Yeah, that's a fair point about JVM culture. I suggest that there's a few cultural reasons this occurs, based on my experience:

1) JVM libs generally tend to follow semver to the Y level of X.Y.Z. reasonably well. (Spring can FOADIAF in this regard though)

2) Maven and Gradle etc. have very good dependency resolution algorithms

3) When the dependency algorithm struggles, you can provide guidance (e.g., Maven's dependencyManagement element, or the ability to exclude a dependency's dependency so that your pinned version of that dependency is what's used)

On that last point, you can use the Enforcer plugin to be very very draconian about transitive dependencies. I worked on a project in the past that would fail the build if you introduced a dependency that had dependencies, and didn't precisely specify the version of each new dependency at the project level.

I've done a fair bit of work also with Python, Go, and JS, and doing so made me realise that the dependency management situation in JVM land is the best I've ever encountered (so far). Which surprised me, I had always thought it somewhat over-engineered, but now I think it's sufficiently engineered and those other languages need to steal some ideas. (Especially Python, I love Poetry, especially compared to pipenv, but I would kill for the ability to override a dependency's dependency like I can in Maven and Gradle).

Re: Just say no to :latest

#133

Post by badLiveware »

ComradePhil wrote: post #44

Terrible advice. It doesn't solve the "immutability" problem and may give you a false sense that it does, which is a much bigger problem. Here's the "good" example from the article: # GOOD: image: "nginx:1.21.6" Here is the header of the source of the Dockerfile for this image: FROM debian:bullseye-slim LABEL maintainer="NGINX Docker Maintainers " ENV NGINX_VERSION 1.21.6 ENV NJS_VERSION 0.7.2 ENV PKG_RELEASE 1~bulls…

The easier solution rather than managing your own OCI registry is likely to just pin the digest and have dependency update automation e.g. renovate update the digest while targeting a tag.

For example

  FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:70b890cd12f73f8ad80061d242081b61da666bda7ec2d729113855a8b9410e1e AS build
Where the tag is used by humans for targeting a tag while the digest locks it to a certain image version

Re: Just say no to :latest

#134

Post by badLiveware »

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...

I am a fan of using renovate, and with docker images in particular since I can define my remote as

  FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:15c22c170650b8db2f6250547a2dc5341978b0647c6b21ef67768e628de614f3 AS build
and have renovate automatically merge digest updates, the sha256 hash, while having manually(or automatic) PRs for the tag target.

So a when upstream updates their tag I get a PR(which is automerged) that looks like so, this allows me to know when upstream has changed while still being able to target a broader version range, 6.0 in this case

  - FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:15c22c170650b8db2f6250547a2dc5341978b0647c6b21ef67768e628de614f3 AS build
  + FROM mcr.microsoft.com/dotnet/sdk:6.0@sha256:70b890cd12f73f8ad80061d242081b61da666bda7ec2d729113855a8b9410e1e AS build

Re: Just say no to :latest

#135

Post by ComradePhil »

izacus wrote: post #94
ComradePhil wrote: post #34

Earlier quoted context omitted.

But it may hinder short-term survival (because you're spending time reinventing the wheel instead of building competitive product). Lockfiles (poetry.lock, Pipfile.lock etc.) solve the survivality problem for the most part.

> But it may hinder short-term survival (because you're spending time reinventing the wheel instead of building competitive product). That's very rare. It's a common trope though and causes amazing examples of startup companies self-destructing themselves when they end up being bogged down in dependency maintenance wars where they're spending a lot of time just fighting all the issues in 100s of alpha libraries they'…

Read my comment in the context of the parent comment I'm replying to and you will see how your comment has nothing to do with mine.
Post reply on HN