
Node Docker image broken - lingz
https://github.com/nodejs/docker-node/issues/649
======
bearjaws
Never ever use :latest unless its in your docker-compose DEV file. Try to
treat docker images like you would dependencies.

We always lock down to specific versions, but we also use a self hosted docker
mirror to cache everything anyway.

~~~
moondev
other labels are mutable too though. That's why this broke for other tags
beside latest. Use the hash instead for a hard link, but obviously won't get
any security updates.

~~~
urda
Security updates should be vetted and not auto-accepted.

There's no problem here.

~~~
moondev
Sounds like a problem that should be solved on the ci/cd level and not the
underlying container registry. People use containers in different ways.

------
zackify
This is one of the reasons I never use the latest version of any docker image,
so I don’t repeat my constant struggles with npm packages breaking on minor
version changes

Edit:

I see they were overwriting current tags.... well that’s even worse

~~~
Cthulhu_
Latest should only be used for hackery / development, but please fix it to a
stable version before release.

Overwriting tags should honestly not be possible, ever. Node / NPM did that (I
think) with one of their versions too. Or was it a npm package?

~~~
derefr
> Overwriting tags should honestly not be possible, ever.

How do you propose to withdraw a release if it’s broken/contains secret
keys/etc.? Delete the image itself and leave the tag dangling?

~~~
casperb
If secrets are published, there is no way to ‘unpublish’ them. Consider them
burned.

But they mean: images can be removed, but you should not be able to publish 2
different images with the same tag. Then you never know which version of those
two you got.

~~~
derefr
“Published” doesn’t always mean “public.” You can publish something to an
internal company repo, and still want to remove it in case an unscrupulous
coworker ever joins and digs through your history.

Also, consider “secrets” in the “Personally Identifiable Information” sense,
or the “confidential information shared to you by a third party” sense. If
these are published, someone might see them; but the longer they _stay_
published, the _more_ people might see them, so you have an obligation to
remove them.

Also, re: reusing a tag, what about having already announced a release version
number, and tagging the release with it, only to find out the release is
broken? It’s kind of problematic to have to bump the version again when the
previous version didn’t even go out to anyone.

I would propose a slightly more relaxed rule: you shouldn’t be able to
erase/overwrite a tag once there exist other tags in the repo with creation or
signing timestamps newer than those of the targeted tag. So you can overwrite
something you just created, but not something that’s “history.”

(An alternative to this would be if tags had nicknames or “object versions”,
like in an S3 bucket. If you could have a v1.0.0 “tag” that first pointed to a
static v1.0.0+1 ref, and then to a v1.0.0+2 ref, where clients don’t see the
static ref tags but can still check them out using some special syntax in
combination with the visible tag—and where you can revoke a static ref, but
not overwrite it—that’d probably make everyone happy.)

------
dozzie
Ah yes, this happens from time to time when you use somebody else's
repositories with somebody else's package retention. That's why production
should only use repositories that change in ways that are predictable to you
(OS upstream, your own, and usually nothing else).

~~~
timwis
huh? so like, don't use open source libraries?

~~~
jasonlotito
That's not what the OP is trying to say, though they have a hard time coming
out and saying it, and their reply to you doesn't help matters.

Instead, what they are saying is that you should 1) use a specific version,
and 2) host that version in a location you control. This way, updates don't
impact your build just because you clamp to the latest (which is a moving
target). Also, if they happen to rerelease a tag which worked for a previous
build you made and now doesn't, you are still pulling in the same thing.

Basically, if you depend on something, host it yourself. Otherwise, you are
asking to be bit by this.

~~~
derefr
> host that version in a location you control

I don’t see how this is implied or required by what the GP said. Lockfiles
exist; docker-image and OS package hash-refs exist. Heck, nix exists. Getting
what you expected to get is a solved problem, and does not require “host[ing]
it yourself.”

Now, _availability_ of your deployment might require hosting it yourself.
(Though more often your availability figures will be far worse than those of
Docker Hub or launchpad.net.)

~~~
nucleardog
I mean, up until last year someone could permanently depublish entire packages
from certain package managers without restriction. No amount of hash-refs are
going to ensure you have the right package if it just doesn't exist anymore.

I think availability is exactly what dozzie was getting at by specifying
'production'.

You want your production systems to be robust, not reliable at the whims of
half a dozen different ecosystems all with different policies, procedures,
humans, support agreements, etc. (This is without even touching on
infrastructure availability.)

------
pmarreck
Was this untested or something?

I certainly don't see any unit tests as part of the commit that triggered this
issue

(Yes, even, or perhaps especially, command line commands should be tested,
somehow.)

------
tkone
well i mean it's broken if you use yarn. which isn't a standard part of node,
so like, not really?

~~~
lainga
It's not standard, true, but it's also not an experimental feature, so one
still wouldn't expect them to do wacky things like overwrite tags. I think
many people expect version tagged code to not change, unless the developers
specifically say they are nightly/experimental (there is a comment to that
effect on the issue link).

------
jlg23
How comes a 7 hour old, now closed, bug report on some dead simple bridging
tech that abuses tags in their SCM is news?

