Package container images as Linux packages

[almet]

For Linux distributions, we could use the already-in-place package manager (apt, dnf) to install new versions of the image.

Images will need to contain the following assets:

• The container image itself, potentially in .tar.gz form
• The signatures.json file, containing everything needed to verify the authenticity of the container image.

Packages might depend on a specific Dangerzone version. For now, I believe it's best to only support one set of images per Dangerzone release (e.g. old container images might work, but we'll not distribute them ourselves).

We'll need to distribute a public key to our users, and I believe it's good enough to have it packaged in dangerzone itself. If we believe it makes sense to package it otherwise, we could have a dangerzone-publickey package for it, but I think it's un-necessary as of now.

Downside: when doing updates this way, we loose the ability to reuse old image layers.

[eloquence]

Would an alternative to this approach be to a) provide container image updates in a format that can be downloaded/applied for air-gapped users, b) otherwise default to a fully in-app update mechanism?

My main concern is the effort involve in maintaining effectively two independent update/notification pathways (Mac/Windows vs. Linux). Moreover, I think we want the same convenience that Linux users get via package updates for Mac/Windows users, in order to achieve the maximum security impact.

IMO this does not necessarily conflict with the idea of having a thin Debian package, and would be similar to https://packages.debian.org/bookworm/torbrowser-launcher

[almet]

Would an alternative to this approach be to a) provide container image updates in a format that can be downloaded/applied for air-gapped users, b) otherwise default to a fully in-app update mechanism?

Yep, it would work.

Finding ways to reduce the maintenance cost of Dangerzone being one of the reasons behind independent container updates, I tend to agree with you on this.

I'd say: let's start without specific packages, and with an identical update mechanism for all platforms, and revisit this if/when a problem arises.

[almet]

One thing to note on the matter: having separate packages with the images would certainly ease inclusion for Debian upstream (and Tails), which would lower the maintenance burden on the long run.

Not a hard requirement for now, but might happen when/if we decide to get down that road. My personal preference is to target this, as it will allow to relax the "one package for all distributions".

Even in these situations, we could also have an "update in-place" mechanism, when possible.

One thing @apyrgio noted is that the Github Container Registry isn't currently available via Tor, which might be problematic for distributions such as Tails, hence why having another update mechanism would be helpful here, but that can be considered a separate issue.

[eloquence]

Thanks @almet, very helpful.

One thing to note on the matter: having separate packages with the images would certainly ease #1007

Is there precedent for distribution of container images another package depends on via Debian main? I wonder if Dangerzone might be a better fit for contrib, similar to torbrowser-launcher, in which case downloading the images dynamically via in-app updates might be less of an issue.

(To be clear I'm not necessarily opposed to packaging the images - just trying to better understand the pros and cons, especially in light of usability & maintenance considerations across all supported platforms, including Win/Mac.)

[legoktm]

One thing to note on the matter: having separate packages with the images would certainly ease #1007 (and Tails), which would lower the maintenance burden on the long run.

Is there precedent for distribution of container images another package depends on via Debian main?

I can't think of any off the top of my head and I wouldn't be a fan of that personally. I could see Tails preferring packages instead of needing to fetch a container image for just DZ, but would be good to confirm with them.

I wonder if Dangerzone might be a better fit for contrib, similar to torbrowser-launcher, in which case downloading the images dynamically via in-app updates might be less of an issue.

Yeah, I think contrib is where we should first aim for. Here's what I had written back in April 2022: "My opinion of ideal behavior would be that the first time Dangerzone is opened, it notices the lack of the image, and then starts building it or pulling it from somewhere (with or without a prompt)." Building locally would allow for inclusion in main, not sure if that would also pull in more dependencies.

[almet]

Thanks for the follow-up @eloquence, and for chiming in @legoktm, that helps.

Note

While talking about this, I might mention that one of the other issues we've had when packaging for Debian is the need to vendorize pymudf (#940), and soon cosign (#1062) when they're not available, but Trixie has both of them handy so we should be covered here.

---

Is there precedent for distribution of container images another package depends on via Debian main? I wonder if Dangerzone might be a better fit for contrib, similar to torbrowser-launcher, in which case downloading the images dynamically via in-app updates might be less of an issue.

I didn't manage to find other packages including images like we would like to do / are doing, but I might have missed them.

Broadening the criteria to other assets (not only container images), we can find multiple games in a similar situation shipping -data packages (example for 0ad-data) containing assets, even on the debian main repo.

I could see Tails preferring packages instead of needing to fetch a container image for just DZ, but would be good to confirm with them.

I have a discussion planned with them next week, I'll make sure to mention this.

Yeah, I think contrib is where we should first aim for. Here's what I had written back in April 2022: "My opinion of ideal behavior would be that the first time Dangerzone is opened, it notices the lack of the image, and then starts building it or pulling it from somewhere (with or without a prompt)." Building locally would allow for inclusion in main, not sure if that would also pull in more dependencies.

Since we now have a way to reproduce the containers locally, building the image locally might be a viable option. Two thoughts about it:

• We would still need to get the signatures for this container release somehow.
• This might take more time and resources, akin to building from source vs using a binary, and might not be practical on some old machines.

About Debian contrib:

The contrib archive area contains supplemental packages intended to work with the Debian distribution, but which require software outside of the distribution to either build or function.

https://www.debian.org/doc/debian-policy/ch-archive#s-contrib

Which kinda match what we are trying to do, but... well, the whole point of this discussion is to see if the containers themselves could be part of the distribution 🙃

I'm curious about the reasons not to target main. It could be acceptable, but also adds another step for users to enable the contrib archive, which might trouble non tech-savy folks (just seen that happen the other day for torbrowser-launcher).

I wouldn't be a fan of that [including the containers in external debian packages] personally

I'm genuinely curious as to the reasons behind this preference, could you expand a bit as to why?