Should a flatpak mail client be able to do gpg operations with keys in the host OS?

detrout commented 5 years ago

Maybe there's a way of making GPG's cryptocard support function over a flatpak portal?

If I understand how that works, that should allow encryption & signing operations to happen without exposing the private keys to the container.

danvratil commented 5 years ago

Hmm...it definitely should, it's one of our main selling points :-) I don't know how the cryptocard works, but I'm afraid it may not be enough - we also need to be able to list all your keys in Kontact settings etc., would cryptocard be enough for that?

One option is just granting access to host's ~/.gnupg - it would expose your private keys to the container, but it should just work. And one could assume that our Flatpak from Flathub is trustworthy enough to do so. Another option is granting access to host's gpg-agent's socket so that gpg inside of Flatpak can talk to host's gpg-agent and dirmngr - as far as I know, the gpg library only executes the gpg executable and parses its output - I don't know how much the gpg executable does directly (would it work without seeing ~/.gnupg?) and how much it just needs to be able to talk to gpg-agent and dirmngr.

@AndreHeinecke, could you maybe comment on what could be the best way to being able to bridge the gpg inside of the sandbox with the keys on host system?

AndreHeinecke commented 5 years ago

I do not have experience with cryptocard in specific and flatpack but some notes on GnuPG / Smartcards in general:

For good smartcard support you should use GnuPG 2.x
If you have a smartcard your keys remain on the smartcard regardless and are protected. If you want to protect each operation you have to configure your smartcard to require a pin each time.
If you have a gpg-agent / scdeamon (the smart card access process) running outside your sandbox and inside, too there can be conflicts because only one scdaemon can access the smartcard at a time.
Regardless of weather or not you start a gpg-agent in your sandbox or access a running one you need the public key and private keystubs available in the sandbox (~/.gnupg)
If you want to access the gpg-agent / scdaemon of your host system you need to also include (for 2.2 versions) /var/run/user//gnupg in the sandbox because that is where the sockets for the processes live by default. Alternatively you can configure an extra socket / socket forwarding with gnupg to access / place the socket for the sandbox from a different location. Please refer to the gpg documentation how to do this.

detrout commented 5 years ago

how much trouble can a rogue app cause with access to the gnupg sockets?

I'm guessing an app can sign/encrypt/decrypt in the background if the key is unlocked, but could a rogue application get access to the private key material via the socket?

AndreHeinecke commented 5 years ago

No an application could not get access to the private key material. Especially not if it is on a smartcard / token. Smartcards by design ensure that the private key material never leaves the card.

wrt. sign/encrypt/decrypt in the background you are right.

ahayzen commented 5 years ago

Long term I think that a GPG portal would be useful here, there is some discussion here https://github.com/flatpak/xdg-desktop-portal/issues/178

travier commented 2 years ago

To make GnuPG work, you can add:

    "--socket=gpg-agent",
    "--filesystem=~/.gnupg:create",
    "--filesystem=xdg-run/gnupg:ro",

Whether or not this should be done by default here is another question.

See discussion in https://github.com/flathub/flathub/pull/3182.

flathub / org.kde.kontact

Should a flatpak mail client be able to do gpg operations with keys in the host OS? #12