Use abbreviated months in the Debian changelog, else we'll have warnings
like the following:
LINE: -- Freedom of the Press Foundation <info@freedom.press> Mon, 31 March 2025 15:57:18 +0300
dpkg-source: warning: dangerzone/debian/changelog(l5): cannot parse non-conformant date '31 March 20
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 change adds the registry prefix to the `debian` image we pull
from `docker.io/library`. By adding this, we improve support for
non-interactive builds, as users who do not have a preferred default
registry defined in their local configuration will no longer be prompted
to select which registry to pull this from.
66600f32dc introduced various improvements
to the determinism of the container image in this repository. This
change builds on this effort by ensuring that the base image is pulled
by digest. Image digests are immutable references, unlike tags, which
are mutable (except when optionally configured as immutable in certain
container registries, but not `docker.io`).
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.
Update our `RELEASE.md` so that we don't forget to bump the download
links in `INSTALL.md` prior to tagging a release. This way, we won't
have a versioned `INSTALL.md` page pointing to an older download link.
Note that this means that the latest version of the `INSTALL.md` page
will point to a broken link, in the short period of time between the
pre-release and the actual release. That's not an issue in our case,
because we don't point to the latest version of our `INSTALL.md` from
our `README.md`. We use versioned links instead, and thus we minimize
the chance that a user may encounter a broken link.
Fixes#1100
This is useful to reduce the computation time when creating PDF visual
diffs. Here is a comparison of the same operation using python arrays
and numpy arrays + lookups:
Python arrays:
```
diff took 5.094218431997433 seconds
diff took 3.1553626069980965 seconds
diff took 3.3721952960004273 seconds
diff took 3.2134646750018874 seconds
diff took 3.3410625500000606 seconds
diff took 3.2893160990024626 seconds
```
Numpy:
```
diff took 0.13705662599750212 seconds
diff took 0.05698924000171246 seconds
diff took 0.15319590600120137 seconds
diff took 0.06126453700198908 seconds
diff took 0.12916332699751365 seconds
diff took 0.05839455900058965 seconds
Currently, this is only returning warnings, but we seem to just skip
them. As it's possible to merge PRs when the CI is red, issuing an error
would help us to think about populating this file.
Create a reusable GitHub Actions workflow that does the following:
1. Create a multi-architecture container image for Dangerzone, instead
of having two different tarballs (or no option at all)
2. Build the Dangerzone container image on our supported architectures
(linux/amd64 and linux/arm64). It so happens that GitHub also offers
ARM machine runners, which speeds up the build.
3. Combine the images from these two architectures into one, multi-arch
image.
4. Generate provenance info for each manifest, and the root manifest
list.
5. Check the image's reproduciblity.
Also, remove an older CI job for checking the reproducibility of the
image, which is now obsolete.
Fixes#1035
Make a major change to the `reproduce-image.py` script: drop `diffoci`,
build the container image, and ensure it has the exact same hash as the
source image.
We can drop the `diffoci` script when comparing the two images, because
we are now able build bit-for-bit reproducible images.
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.
Invoke the `repro-build` script when building a container image, instead
of the underlying Docker/Podman commands. The `repro-build` script
handles the underlying complexity to call Docker/Podman in a manner that
makes the image reproducible.
Moreover, mirror some arguments from the `repro-build` script, so that
consumers of `build-image.py` can pass them to it.
Important: the resulting image will be in .tar format, not .tar.gz,
starting from this commit. This means that our tests will be broken for
the next few commits.
Fixes#1074
Vendor the `repro-build` script in our codebase, which will be used to
build our container image in a reproducible manner. We prefer to copy it
verbatim for the time-being, since its interface is not stable enough,
and the repro-build repo is not reviewed after all.
In the future, we want to store this script in a separate place, and
pull it when necessary.
Refs #1085
Make our container image more reproducible, by changing the following in
our Dockerfile:
1. Touch `/etc/apt/sources.list` with a UTC timestamp. Else, builds on
different countries (!?) may result to different Unix epochs for the
same date, and therefore different modification time for the
file.
2. Turn the third column of `/etc/shadow` (date of last password change)
for the `dangerzone` user into a constant number.
3. Fix r-s file permissions in some copied files, due to inconsistent
COPY behavior in containerized vs non-containerized Buildkit. This
requires creating a full file hierarchy in a separate directory (see
new_root/).
4. Set a specific modification time for the entrypoint script, because
rewrite-timestamp=true does not overwrite it.
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
Unpin the PyMuPDF package that we vendor in our Debian packages. We
originally pinned it to version 1.24.11, because it was the last version
that supported Ubuntu Focal, but we can now unpin it, since we have
dropped Ubuntu Focal support.
Fixes#1018
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
Scan ARM images using Anchore's scan action, by utilizing the Ubuntu ARM
runners provided by GitHub. While our ARM images are used only in macOS
silicon platforms, we can use the Ubuntu ARM runners just for scanning.
Closes#1008
Update our CI job and build instructions with the latest WiX version, so
that we don't encounter any installation issues when new WiX versions
are released.
Also, add a reminder in our release instruction to bump the WiX version
before we start a new release.
Fixes#1087
