-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Host your own docker image #154
Comments
We are currently discussing basically the same issue in preparation for packaging Dangerzone for Debian (and hopefully that'll make it available for downstreams like Tails too): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986856#29 Building and shipping such a large container is impractical and also has technical blockers, whether it's the chroot issue or lack of network access in the builder. Providing a pre-built image would be one way to fix it, maybe with a nice GUI progress bar when it gets downloaded on first use. Or maybe have Dangerzone build the image on first use, so it doesn't need to be hosted anywhere, but also doesn't need to be taken care of at package build time. |
I also run into this question/decision while experimenting with my own dangerzone-like tool. I chose to default to a pre-built Dockerhub image, while still allowing an option to use a custom container image (potentially self-hosted/self-built).
|
Looking a bit at the project's history, I've found that pulling on install was the way it worked before. There was an image hosted on docker hub instead of it being shipped at install time. |
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=dangerzone This is primarily just a bump to remind people of this issue, and the fact this package hasn't worked properly for 8 months. |
Thanks for the bump Rojikku. Indeed, it would be nice separating the container image from the application package. Before this happens, we need to tackle issues such as airgapped installations and privacy. But I'd like to focus on the I spent some time testing Dangerzone in a fully containerized environment, and I've built the container image in one, using our provided script (
So, I have some questions, if you don't mind digging into this a bit:
|
I think the airgap and privacy options are easily resolved by allowing people to build their own instances, just like they can now. Having one publicly built and offered wouldn't change your existing infrastructure, beyond setting one to build on say ghcr.
These are the errors I get with build-image.sh I would caution you with the fact that the package still builds with those errors, but does not, in fact, contain the container needed for the application to run properly. This is presumably tied to the fact that I'm running a script instead of the commands directly, and the script doesn't set an exit status when it fails. For your second question, no.
That is the error I get. For your third question, I feel it demonstrates a misunderstanding on how the AUR works. What these methods have in common, is that they usually chroot the pkgbuild to produce a consistent build environment without messing with the overarching environment, as well as to avoid....critical system errors in the event of a malicious maintainer, as AUR maintainers aren't considered "trusted" maintainers by default, until they build up a certain reputation.
Hopefully this clears things up a bit, thanks for looking into this! |
Thanks a lot for the error logs @Rojikku, and the useful insights. I think I get the limitation you're seeing; the |
Hosting the image on DockerHub doesn't look like an option anymore (at least one the free plan): HN: Docker is deleting Open Source organisations - what you need to know |
Any news on this issue ? Any new plans following @deeplow's comment ? |
Unfortunately, we don't have something new in this front. We were busy moving the release infra to FPF's servers and keys, and now we're trying to tackle the Qubes OS integration, so that Dangerzone is available to SecureDrop Workstation users. These are big undertakings, and our main focus is there. The first step towards this issue the fact that we will create .deb/.rpms for Qubes OS that will not have that container image. After that, the road will be more clear. But I don't want to make promises until we have something concrete. Still, we may have something that will help package maintainers: we now provide the container image (for x86_64 architectures) through our release page: https://github.com/freedomofpress/dangerzone/releases/tag/v0.4.1. If build scripts can treat this image as an artifact, then hopefully we have a way forward. @AkechiShiro, just to make sure, are you asking because you're interested in packaging Dangerzone? |
@Rojikku, I found a similar error regarding the lack of sub*ids in rootless when I tried to run any of the supported Linux distributions Ubuntu / Debian / Fedora on top of Oracle Linux. The way to overcome such issue was to include this line in Dockerfile: I hope this helps! |
Greetings.
I maintain https://aur.archlinux.org/packages/dangerzone so people in the Arch based distributions can potentially install dangerzone.
It worked fine until podman.
I thought it was because I setup podman wrong. I looked further into it upon user complaint, and the issue is actually because you want me to build the container image.
You provide a nice script. I get it. But it doesn't work in chroots.
Most installers that use PKGBUILDs build the package in chroots, and I try to write things to work in chroots.
I have spent two and a half hours attempting to get this to build in a chroot, and I cannot. The podman community does not have a solution thus far, nor does google.
Resolution:
Please build and host your own dockerimage. Github and Dockerhub will both happily use your existing dockerfile to do this. It should cost you nothing.
I do not believe it is possible to build a docker container in a chroot unless you configure it in some way. I don't think that's going to work very well at all on a variety of systems. It's just not good. Hosting your own image solves this problem.
Possible outcomes:
Alternatively, if you ask, I will be happy to disown this package- enabling anyone who wishes to become the maintainer (I.E. you, since you probably know what you're doing).
Also this will solve #152
The text was updated successfully, but these errors were encountered: