freedomofpress
Independent container updates
This pull request introduces "independent container updates", meaning that the container images will be able to be updated without issuing a new release, allowing for greater security. You can read more about the rationale at #1006.
Signatures are meant to be done with an hardware key (yubikey), for which the public key will be packaged alongside the shipped code.
On container installation, the container signatures are stored locally and checked against a known public key just before doing the conversion of the documents. Behind the curtain, it uses cosign, which enables us to have auditable signatures (so if somebody is to impersonate us, they would need to do so in public).
Graphical interface
The graphical interface has been updated to ask users if they want Dangerzone to check for container updates and apply them on their behalf. The updater_check setting is now deprecated and replaced by updater_icu_check.
Command-line interface
It adds a dangerzone-image CLI providing tooling to check for remote new images, verification of the attestations and signatures, also with the ability to create and use archives, for air-gapped environments.
$ dangerzone-image --help
attest-provenance Look up the image attestation to see if the image...
get-manifest Retrieves a remote manifest for a given image and...
list-remote-tags List the tags available for a given image.
load-archive Upgrade the local image to the one in the archive.
prepare-archive Prepare an archive to upgrade the dangerzone image...
upgrade Upgrade the image to the latest signed version.
verify-local Verify the local image signature against a public...
It is fixing the following issues:
- #1064
- #1065
- #1066
- #1068
- #1070
- #1035
Current progress
Before being ready to be shipped, we still need to:
- [x] Fix the linter
- [x] Implement unit tests
- [x] signatures
- [x] registry
- [x] Implement the UI, related to the discussion on #1079
- [ ] Publish and sign test images / use them in tests
- [ ] Remove the old images (both with the new and the old format)
- [ ] Make it work with Docker
- [ ] Package/vendorize cosign (#1062)
I'm in the final stages of the review Alexis, but I just wanted to say: :sparkles: freaking awesome work :sparkles: ! There were several places in the code where I was like "oh neat!", but I didn't track them I'm afraid :disappointed: .
(there should be a :star_struck: reaction or something for specific lines of code. it's a shame if reviews are just "here's one comment, and here's another one", and let good decisions not be rewarded or anything. Anyway, food for thought...)
Anyways, what I haven't reviewed yet is the airgapped logic, the docs, and the tests. I'll switch to updating the reproduce image script based on the repro-build work that I did, if that's ok with you.
Note: Cosign bundling is now basically done now in this independent-container-updates branch, alongside some packaging work that was needed to get the new dangerzone-image tool to be available to all distributions we support.
Congrats on all the progress here so far. A couple of comments on the dialog:
-
I still hope we revisit the Dangerzone icon eventually, but with the current icon, the "warning" connotation is IMO especially problematic in a message prompt like this. It may suggest to the user that the application failed to start, or that it detected a problem. I would recommend replacing the icon with a generic question-mark symbol typical for such prompts.
-
The dialog message itself is a bit long and technical. I think we need to carefully examine this message from the perspective of 1) what is the core point that we're trying to bring across, 2) how can we do this in a straightforward way without imposing too much cognitive burden on the user.
As I understand it, we are not planning to do regular Dangerzone releases for every sandbox update (that's the point of having ICUs). So if a user wants to stay secure, they really need automatic sandbox updates, or they need to use dangerzone-image. If that is correct, then I think we want to be very clear about the importance for security, while making the path for networkless usage clear.
Here's an attempt to do that:
Enable automatic sandbox updates?
If enabled, Dangerzone will periodically fetch and install updates for the internal sandbox that it uses to convert documents. It will also notify you of new Dangerzone releases.
This is recommended in most settings. For alternative methods to keep Dangerzone up-to-date and secure (e.g., in a networkless environment), see our documentation.
No, disable sandbox updates Yes, enable sandbox updates
- I still hope we revisit the Dangerzone icon eventually, but with the current icon, the "warning" connotation is IMO especially problematic in a message prompt like this. It may suggest to the user that the application failed to start, or that it detected a problem.
I'm 100% behind you on this. About the logo, but also in general about the "Dangerzone" name. It conveys something dangerous, and potentially non-american speakers don't get the movie-related joke. I've had feedback from non-tech people pointing in the direction that it could be a barrier to adoption.
The thing is: names are hard, and I believe the tool is (relatively) well known amongst journalists, which might point in the direction of keeping it. At any rate, the logo could change without triggering the big "let's change the name" discussion.
I would recommend replacing the icon with a generic question-mark symbol typical for such prompts.
I will, thanks.
* The dialog message itself is a bit long and technical. I think we need to carefully examine this message from the perspective of 1) what is the core point that we're trying to bring across, 2) how can we do this in a straightforward way without imposing too much cognitive burden on the user.
Also agree with you on this. I'm curious about @harrislapiroff feedback on this one as well. Pointing out https://github.com/freedomofpress/dangerzone/issues/1079 for completeness.
As I understand it, we are not planning to do regular Dangerzone releases for every sandbox update (that's the point of having ICUs). So if a user wants to stay secure, they really need automatic sandbox updates, or they need to use
dangerzone-image. If that is correct, then I think we want to be very clear about the importance for security, while making the path for networkless usage clear.
You got this correctly, yes.
And yes, disabling security updates should be the last option people consider. In fact, we could probably be even smarter than that and hide to option, or even not make it possible at all. After all, I believe this whole "let's not do any HTTP requests" thing would be counter-productive to our use case as it seems to be always better to get security patches.
The only place where this makes sense is for air-gapped environments, where... well actually, we could just let the requests fail.
For now I'll replace the dialog with what you're proposing, and we can continue discussing this here or elsewhere, in case it makes sense.
The tests are now green on this branch (you can see this here), and I rebased everything in a series of only 18 commits (from almost 200+ commits in total :sweat_smile:)
Here's the plan to go forward:
- I want to review myself the PR once again. It's been a marathon, and I've left some things aside with comments ;
- We want to have a discussion with Ethan when he's back in order to go forward on the situation with GH PATs ;
- I want to have another look at the documentation, as it probably requires some changes.
- Reviewing the comments here, I realize that I want to remove the "danger" icon from the alerting mechanism that shows when the users are asked if they want to enable upgrades.
- Ask for another review by @apyrgio
- Address the issues.
Once that's done, I believe we can merge!
If/When we ship the content inside the branch, it will break main, because the archives produced are not able to be loaded by Docker. It's okay and something we do on purpose, but the way to solve this situation is to embed podman, as described in #1145.
In the meeting today, we've been discussing a way to have some sort of feature flags.
If we turn off the automatic updates, the only difference between the "old" way of installing containers and the "new" is the image archive format and the fact that we check for signatures or not.
Meaning that ICU could be disabled, requiring as well a different way (the old one) to produce the image archives, and disabling the security checks.
I'm wary of having the signature checks disabled by the settings as it could be leveraged by an attacker to remove all the work done to ensure that the image we run are the images we think we run, but that might be okay if we decide to do that while in this transient state.
Of course, one other way to solve this is to wait until we have podman embedded done, merge this work inside this branch and then everything in main. That would require continuing tracking the main branch, but I've been doing that in the past months and that proved to be no major headache, so I would actually advocate for doing that as it seems less complicated to do that having a way to disable ICU.
:heavy_check_mark: The CI for the Independent Container Updates is now green.
I've just updated the base branch to be test/main-icu, which will be the base branch for all ICU-related changes starting now, and so I believe we're good to merge this.
@apyrgio let me know if I can merge!
~Blue~Green is the warmest color :face_holding_back_tears:
The diff from the stored version of ICU that I had locally looks ok to me. If there's anything CI-related that you wanna bring to my attention, let me know. Else, feel free to merge!