QA and release Dangerzone 0.4.2

[apyrgio]

To ensure that new releases do not introduce regressions, and support existing and newer platforms, we have to run some QA tests. Copied from RELEASE.md:

• In .circleci/config.yml, add new platforms and remove obsolete platforms
• Bump the Python dependencies using poetry lock
• Make sure that the tip of the main branch passes the CI tests.
• Create a test build in Windows and make sure it works:
  • Check if the suggested Python version is still supported.
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests.
  • Build and run the Dangerzone .exe
  • Test some QA scenarios (see Scenarios below).
• Create a test build in macOS (Intel CPU) and make sure it works:
  • Check if the suggested Python version is still supported.
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests.
  • Create and run an app bundle.
  • Test some QA scenarios (see Scenarios below).
• Create a test build in macOS (M1/2 CPU) and make sure it works:
  • Check if the suggested Python version is still supported.
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests.
  • Create and run an app bundle.
  • Test some QA scenarios (see Scenarios below).
• Create a test build in the most recent Ubuntu LTS platform (Ubuntu 22.04
  as of writing this) and make sure it works:
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests.
  • Create a .deb package and install it system-wide.
  • Test some QA scenarios (see Scenarios below).
• Create a test build in the most recent Fedora platform (Fedora 38 as of
  writing this) and make sure it works:
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests.
  • Create an .rpm package and install it system-wide.
  • Test some QA scenarios (see Scenarios below).
• Release Dangerzone 0.4.2 for Mac, Windows and Linux
• Create a test build in the most recent Fedora template in Qubes OS (Fedora 38 as of
  writing this) and make sure it works:
  • Create a new development environment with Poetry.
  • Build the container image and ensure the development environment uses
    the new image.
  • Run the Dangerzone tests and confirm that the tests are ran using containers
    instead of disposable qubes
  • Run the Dangerzone tests with the env var QUBES_CONVERSION=1 and confirm that
    the tests are ran using diposable qubes instead of containers
  • Create an .rpm with ./install/linux/build-rpm.py package and
    install it in a fedora qube and make sure conversions run with containers (skipped, see below)
  • Create an .rpm with ./install/linux/build-rpm.py --qubes package and
    install it following the instructions in BUILD.md
  • Test some QA scenarios (see Scenarios below).

(see also the previous QA for 0.4.1)

[apyrgio]

The MacOS M1 tests do not pass all test cases, due to #498. If we do not find the fix in time for the release, we will need to inform users somehow that this feature is broken :-/

[deeplow]

When a document fails it's saying the same as in the terminal (UNTRUSTED>). Maybe we can make this more appealing to users visually?

Maybe [UNTRUSTED]. But still it feels odd to see it in the UI like this. Maybe in the future we should add some styling. And in any case this will probably go away since we're moving to client-side error messages for the most part.

[apyrgio]

Yeah, I didn't pour much thought into this, since we want to avoid showing possibly-attacker controlled messages to the user in the first place. In any case, [UNTRUSTED] vs UNTRUSTED> makes little difference to me to warrant a change now. If think it's important though, feel free to send a PR and I'll approve it.

[apyrgio]

I haven't managed to test the following:

Create an .rpm with ./install/linux/build-rpm.py package and install it in a fedora qube and make sure conversions run with containers

due to lack of space and time. But that's something that we have already tested through various way in other steps, so I'm pretty confident that it will work.

[deeplow]

Closing this one since it's now been released.