Proposal: Consider publishing optional keyring+sources package on apt repo for 3rd party tooling

[rocodes]

Description

Background

We don't currently support additional tooling (Signal, Dangerzone, etc) integrated into SecureDrop Workstation, but they are often-requested features and have been discussed as part of our roadmap: freedomofpress/securedrop-workstation#609, sdw readme, freedomofpress/securedrop-workstation#862, freedomofpress/securedrop-workstation#26.

One challenge with getting set up with additional tooling is configuring the (apt/yum) repos and importing signing keys; it's a manual process and could lead to user error (eg: connecting template to a network, rather than downloading in an AppVM and copying to the template, manually configuring a repo list is not super convenient).

Proposal (discussion!)

We could consider hosting a Debian "extras" keyring package on our apt repo, that included the Dangerzone and Signal apt sources info and release signing keys. This would not be a package that we'd install during workstation provisining; and in fact, we could even go so far as to explicitly mark it as conflicts with (some of) our own packages. It would be something that users could install optionally on their own if they wanted, but otherwise wouldn't enter into our provisioning logic.

Pros:

• if/when we do move towards supporting additional tooling like Signal and Dangerzone (two most-requested additional tools), we might want something like this for bootstrapping/automatic provisioning anyway
• Afaik, no one rotates keys like we do 😅 so the maintenance burden wouldn't be that rough (but needs confirmation)
• Much easier for users even if we don't automate; clone eg our large template, apt-get install the extra keyring package, apt-get install the packages they want

Cons:

• Extra maintenance
• Implied trust (what would be our threshold for trusting an external project like this enough to host its key and apt repo?)
• Being aware of upstream changes
• ? (needs discussion)

How will this impact SecureDrop users?

• Make it easier and safer to verify and install additional tooling on Qubes laptops

How would this affect the SecureDrop Workstation threat model?

• Needs discussion, see "implied trust" above, but not directly proposing changes to SDW VMs/components at this point.

User Stories

• As a user, I want to safely and quickly configure additional tooling I need for my workflow.

[legoktm]

This is a good idea, I like the concept of getting keys in a manner that's signed by an already trusted key.

I wonder if we can reuse or benefit from the work done by the extrepo folks (https://manpages.debian.org/bookworm/extrepo/extrepo.1p.en.html). I see that Signal's apt repo is already in https://salsa.debian.org/extrepo-team/extrepo-data/ but not Dangerzone?

[rocodes]

Oh, that's great :) And might fit in nicely with some of Dangerzone's other recent priorities. Probably something to revisit in September.

[deeplow]

(update: whoops, only saw after posting that @legoktm had already mentioned extrepo, the following is the original response)

We could consider hosting a Debian "extras" keyring package on our apt repo, that included the Dangerzone and Signal apt sources info and release signing keys.

So I guess we'd be talking about a kind of like 'trusted by FPF' keyring. It can already be obtained via extrepo:

sudo apt install extrepo
sudo sed -i "s/# - non-free/- non-free/g" /etc/extrepo/config.yaml  # due to disputes in open-sourceness
sudo extrepo --offlinedata enable signal

# And then it's just a matter of installing signal
sudo apt install signal-desktop

However, there was this thread on the Qubes forum, where various solutions to installing signal were proposed, but above all the biggest issue we found was that discoverability is challenging. Even if they install via extrepo or if they can fetch the GPG keyring via the updates proxy like so:

curl --proxy http://127.0.0.1:8082/ https://updates.signal.org/desktop/apt/keys.asc"

The above is unfortunately not very discoverable because when people want to install an application, the usual instinct is to look it up online on the official website.

So personally, even though keyring availability is part of the challenge, I'd actually suggest that we focus on the broader problem installing more Qubes Applications (as Joanna Calls it) / MultiVM applications. This is currently being tracked in QubesOS/qubes-issues#1939 and even though it's focused on distributing salt formulas, I think it should be salt-agnostic in any final solution.

Then adding the FPF-built / trusted formulas would just be a click away from creating a Signal VM or a Dangerzone one. For Dangerzone the Qubes install instructions are (painfully) manual. IMO this is the wider challenge.

To elaborate a bit more, something to consider is having a journalist workstation, where the architecture is already in said formulas, but one can choose individual packages to install with a click of a button. Having one VM per application is not practical on Qubes, so the formulas would lay bare the architecture for what goes where and what can communicate to what. For example, "dangerzone-converter" would be its own disposable, but the dangerzone client could go in the same template as signal.

[rocodes]

So, I agree with everything you're saying @deeplow and I do see the bigger picture issue, and I agree - automated (one click even?) provisioning of multi-VM environments, and friendly interoperability, is my horizon-level goal. I wouldn't stop at users being able to apt-get install a Signal binary, I'd want one-click VM provisining, RPC policies, inter-vm communication protocol... etc; basically an extensible desktop environment, as we've all alluded to.

But since we have so many competing priorities and since those changes are probably a little ways off, what I'm trying to propose here is a 'first step' goal that could serve that broader goal but be something we could do fairly quickly and without a lot of blockers. I don't have strong feelings about what it should be, so I'm glad there's a discussion, but I think my main point was to avoid the pain of key bootstrapping and/or repo bootstrapping if we can, in a way that will set us on the path for all the future work you / we have outlined.