There is now a new setting that is updated when a container upgrade
needs to be applied.
The `UpdaterReport` has been extended to support this scenario, and is
now a python `dataclass`.
This is especially useful when running the tests against some
non-production version of the image. Note that the signature for this
image will need to match the key at `share/freedomofpress-dangerzone-pub.key`
This is done to avoid looking at the internal logic of
`dangerzone.updater`. Only the features that actually are part of
the exposed API are exposed, and do not require deep knowledge of the
updater's logic to be used.
The isolation provider `install()` method is now passed a
`should_upgrade` argument, which is read from the settings and
represents the user decision about updates.
The tests have been updated to reflect these changes.
This can be done with the newly added `--runtime` flag, which needs to
be passed to the first group, e.g:
```bash
dangerzone-cli --runtime docker COMMAND
```
This new setting triggers the same user prompts, but the actual meaning of
it differs, since users will now be accepting to upgrade the container image
rather than just checking for new releases.
Changing the name of the setting will trigger this prompt for all users, effectively
ensuring they want their image to be automatically upgraded.
The code making the actual requests and checks now lives in the
`updater.releases` module. The code should be easier to read and to
reason about.
Tests have been updated to reflect this.
This function does all the needed checks before returning `True`, making it a good external API.
Under the hood, the registry now has an `is_new_remote_image_available`
which is just for checking the presence of a new image, but doesn't do
any verirications on it, and there is also a new `check_signatures_and_logindex` that ensures that these two are valid.
A new `dangerzone-image attest-provenance` script is now available,
making it possible to verify the attestations of an image published on
the github container registry.
Container images are now build nightly and uploaded to the container
registry.
Signatures are stored in the OCI Manifest v2 registry [0], and are
expected to follow the Cosign Signature Specification [0]
The following CLI utilities are provided with `dangerzone-image`:
For checking new container images, upgrading them and downloading them:
- `upgrade` allows to upgrade the current installed image to the
last one available on the OCI registry, downloading and storing the
signatures in the process.
- `verify-local` allows the verify the currently installed image against
downloaded signatures and public key.
To prepare and install archives on air-gapped environments:
- `prepare-archive` helps to prepare an archive to install on another
machine
- `load-archive` helps upgrade the local image to the archive given
in argument.
Signatures are stored locally using the format provided by `cosign
download signature`, and the Rekor log index is used to ensure the
requested-to-install container image is fresher than the one already
present on the system.
[0] https://github.com/sigstore/cosign/blob/main/specs/SIGNATURE_SPEC.md
In case we run on Windows and use Podman Desktop (for which we currently
offer experimental support), we must not pass some Podman flags in order
to avoid conversion errors.
Refs #1127
Update the minimum Docker Desktop version prior to the 0.9.0 release.
The new version should also fix a recent Docker bug, whereby the container
stdout was truncated, and caused our conversions to fail.
Fixes#1101
This sets the container runtime in the settings, and provides an easy
way to do so for users, without having to mess with the json settings.
When setting the container runtime, one can just pass "podman" and the
path to the executable will be stored in the settings.
Loading an image built with Buildkit in Podman 3.4 messes up its name.
The tag somehow becomes the name of the loaded image.
We know that older Podman versions are not generally affected, since
Podman v3.0.1 on Debian Bullseye works properly. Also, Podman v4.0 is
not affected, so it makes sense to target only Podman v3.4 for a fix.
The fix is simple, tag the image properly based on the expected tag from
`share/image-id.txt` and delete the incorrect tag.
Refs containers/podman#16490
Find all references to the `container.tar.gz` file, and replace them
with references to `container.tar`. Moreover, remove the `--no-save`
argument of `build-image.py` since we now always save the image.
Finally, fix some stale references to Poetry, which are not necessary
anymore.
This is a common pitfall of pyinstaller, when using multiprocessing.
In our case, the spawned processes is passed the -B option, thinking
it's python (but it's dangerzone).
> -B Don't write .pyc files on import. See also PYTHONDONTWRITEBYTECODE.
As a result, dangerzone is spawned with the -B option, which doesn't
mean anything for it.
> In the frozen application, sys.executable points to your application
> executable. So when the multiprocessing module in your main process
> attempts to spawn a subprocess (a worker or the resource tracker), it
> runs another instance of your program, with the following arguments for
> resource tracker:
>
> my_program -B -S -I -c "from multiprocessing.resource_tracker import main;main(5)"
https://pyinstaller.org/en/stable/common-issues-and-pitfalls.html#multi-processing
Drop Ubuntu 20.04 (Focal) support, because it's nearing its end-of-life
date. By doing so, we can remove several workarounds and notices we had
in place for this version, and most importantly, remove the pin to our
vendored PyMuPDF package.
Refs #1018
Refs #965
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
Switch base image from Alpine Linux to Debian Stable, in order to reduce
our image footprint, improve our security posture, and build our
container image reproducibly.
Fixes#1046
Refs #1047
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
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] d15cf12b26/repro-sources-list.sh
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.
