Make our Dangerzone image reproducible #1049
Conversation
apyrgio
force-pushed
the
1046-reproducibility
branch
2 times, most recently
from
c1f5d75 to
e02dbfd
Compare
| @@ -0,0 +1,103 @@ | |||
| #!/bin/bash | |||
| # | |||
There was a problem hiding this comment.
We also had a discussion about this file, and if it should be included in this repository or not (the other option would be to download it on the fly, which could be done by the build-image.py script.).
We didn't came up with a conclusion on this one just yet. It feels odd to have it included here, but might work on the short run.
There was a problem hiding this comment.
Hm, would a third party notice make things better? Check out 4595b3a
apyrgio
force-pushed
the
1046-reproducibility
branch
3 times, most recently
from
eaf3de9 to
cbb7ed9
Compare
|
(Also happy to report that the size of the image dropped from 577 MB to 445 MB with the changes in this branch) |
apyrgio
force-pushed
the
1046-reproducibility
branch
4 times, most recently
from
c8a016c to
ac6931f
Compare
Move container-only build context (currently just the entrypoint script) from `dangerzone/gvisor_wrapper` to `dangerzone/container_helpers`. Update the rest of the scripts to use this location as well.
Download and copy the following artifacts that will be used for building a Debian-based Dangerzone container image in the subsequent commits: * The APT key for the gVisor repo [1] * A helper script for building reproducible Debian images [2] [1] https://gvisor.dev/archive.key [2] https://github.com/reproducible-containers/repro-sources-list.sh/blob/d15cf12b26395b857b24fba223b108aff1c91b26/repro-sources-list.sh
Remove the need to copy the Dangerzone container image (used by the inner container) within a wrapper gVisor image (used by the outer container). Instead, use the root of the container filesystem for both containers. We can do this safely because we don't mount any secrets to the container, and because gVisor offers a read-only view of the underlying filesystem Fixes #1048
Remove all the scaffolding in our `build-image.py` script for using the `poetry.lock` file, now that we install PyMuPDF from the Debian repos.
Rename the `vendor-pymupdf.py` script to `debian-vendor-pymupdf.py`, since it's used only when building Debian packages.
Remove our suggestions for not using the container cache, which stemmed from the fact that our Dangerzone image was not reproducible. Now that we have switched to Debian Stable and the Dockerfile is all we need to reproducibly build the exact same container image, we can just use the cache to speed up builds.
Add jinja2-cli as a package dependency, since it will be used to create the Dockerfile from some user parameters and a template.
Allow updating the Dockerfile from a template and some envs, so that it's easier to bump the dates in it.
Update the Debian snapshot date to the current one, so that we always scan the latest image for CVEs. Refs #1057
Allow setting a tag for the container image, when building it with the `build-image.py` script. This should be used for development purposes only, since the proper image name should be dictated by the script.
Add a dev script for Linux platforms that verifies that a source image can be reproducibly built from the current Git commit. The reproducibility check is enforced by the `diffoci` tool, which is downloaded as part of running the script.
Add a CI job that uses the `reproduce.py` dev script to enforce image reproducibility, for every PR that we send to the repo. Fixes #1047
Co-authored-by: Alexis Métaireau <[email protected]>
Mask some paths of the outer container in the OCI config of the inner container. This is done to avoid leaking any sensitive information from Podman / Docker / gVisor, since we reuse the same rootfs Refs #1048
apyrgio
force-pushed
the
1046-reproducibility
branch
from
06fe63b to
3cf34e6
Compare
|
I've updated this PR with a way to separate the rootfs of the inner and outer container image, but reuse the same I've also rebased it on top of the Let me know your thoughts, thanks! |
|
Sigh, I just realized something important while scanning the final image with Grype; Grype does not detect vulnerabilities for the inner container image. It could do that for the Alpine one, but it seems it doesn't do it for the Debian one. This could also be due to the fact that we use scratch images (see anchore/grype#383), or because we haven't copied the So, it seems that I need to dig more into it :-/ |
apyrgio
force-pushed
the
1046-reproducibility
branch
from
27ac422 to
e388fe6
Compare
This PR makes our container image reproducible, and enforces it with a CI job on every commit. To do so, we also change our base image from Alpine Linux to Debian Stable, and we use some prior art and tooling from the work that @AkihiroSuda has done on reproducible containers.
Fixes #1046
Fixes #1047
Fixes #1048