Please offer a download link for latest release, e.g. ttps://github.com/krallin/tini/releases/download/latest/tini about tini HOT 6 CLOSED

I'm unlikely to do this. Besides the fact that I'm not sure I can easily do that with Github releases to begin with, I'd rather not get in a position where breaking changes have to be held back even across major releases, because some users might have chosen not to pin their versions: I've been bitten by this before.

If you have a large number of images, I would recommend using a base image in which you install Tini,a and building your other images off of that one. That way, if you want to upgrade Tini, you only have one image to update.

Cheers,

from tini.

Then why not make a tini api version or something? https://github.com/krallin/tini/releases/download/latest-api1/tini

Base image doesn't make much sense unless there is a tini base image on dockerhub to derivate from. I share my Dockerfiles with people sometimes, and requiring a special base image only I have would greatly interfere with that. Maybe an official ubuntu tini image might be an idea?

from tini.

Then why not make a tini api version or something? https://github.com/krallin/tini/releases/download/latest-api1/tini

Tini simply does not change very often (because it's intentionally minimal as a piece of software), so I don't think it's worth maintaining this kind of complexity in its release process for no clear benefit.

If you absolutely need to upgrade Tini centrally and it's a major pain point for you, then I would recommend simply hosting the binaries for yourself, on AWS S3 or another object store.

Cheers,

(as an aside, there is in fact a base Ubuntu Tini image, but it's intended to simply use the core zombie reaping and signal forwarding functionality of Tini, so for now it's still on an older version since that functionality hasn't changed since)

from tini.

You're slightly missing the point, so let me elaborate: the problem isn't the pain of an upgrade but rather if you ever release a security update, I know I and a lot of other people will likely forget to upgrade it in some of their images. That's why I don't pin versions intentionally, because I don't run super important production stuff and I'd rather have a broken image (which is something I'll instantly notice and fix) rather than have a literally open door for anyone to hack in (which I might not notice for months).

All your solutions are targeted at large deployments which have employed people to take care of this anyway and will find a way to fix it. But for people with small servers that run a few custom images, this can be an issue if they're forced to pin the version.

from tini.

In that case, I would recommend relying on a distro to package and keep Tini updated for you. It is currently packaged in Alpine and Nix. I think it'd be good to try and get it packaged in Debian and Ubuntu, but that's not done as of yet AFAIK.

In any case, I do understand your point, although I think the threat model is a bit misguided here. Downloading a "latest" binary has its own risks since you can't checksum it. I'm sure you will account for this, but if I provide a latest binary and download instructions for it, others may not.

Taking a step back, you're looking at this from your personal perspective and focusing on how I can fix your problem, but I'm afraid you're not considering how this fix will affect me and what I can do with Tini: you would rather have a broken image than one that's not up to date, but other users may not share your opinion. If I set up a "latest" URL, and have to release a breaking change at some point, you won't complain about it, but I can certainly guarantee that others will (which is why I'm not goin to do it).

So, as I mentioned originally, I'm not planning on delivering this. In any case, I'm a lot more likely to work towards getting this packaged into more distributions (note: this is something others can contribute to as well) than I am to ever offer a "latest" URL.

from tini.

Yea, a distro package I'd use instantly. That sounds like a perfect solution, so I hope there will be an Ubuntu package eventually. I don't really like Alpine because I'm not that super tight on disk space and I prefer to have a similar environment inside and outside of the containers, but I might use it now for tini alone. Thanks for the suggestion!

Downloading a "latest" binary has its own risks since you can't checksum it.

Maybe, but HTTPS is not as insecure as you give it credit for (of course for a state-level attacker it is, but then you have other problems...).

TL;DR: will consider using Alpine for now, but Ubuntu/Debian packages would be really nice to have!

from tini.