WIP: Gpg agent support

[cmollekopf]

I've looked into adding gpg-agent access, but this will require some work still.

This patch mounts the gpg-agent-extra socket (https://jlk.fjfi.cvut.cz/arch/manpages/man/gpg-agent.1 see the --extra-socket option) with has a reduced command set (so arguably more secure), but still allows for encryption & signing as a proof of concept. We may want to add two flags for gpg-agent and gpg-agent-extra (I think being able to do key-management from a flatpak'd app is a valid usecase as well.)

For gpg to work as expected inside the container it is still required to "chmod 700 /run/user/1000/gnupg", which I have failed to do from flatpak so far (doesn't look like bubblewrap has the necessary options?)

I'd like to get some feedback on whether this approach has potential to be accepted, and if yes some guidance with the chmod part above. I would then also add both the gpg-agent and gpg-agent-extra flags (if you agree)

For the usecase: I have an email application that uses gpgme. Currently I'm starting a gpg-agent inside the container, which means the agent has to be unlocked every time I open the application.
By using the system gpg-agent this can be avoided and the agent only needs to be unlocked once.

[rh-atomic-bot]

Can one of the admins verify this patch?
I understand the following commands:

• bot, add author to whitelist
• bot, test pull request
• bot, test pull request once

[cmollekopf]

According to containers/bubblewrap#346 bubblewrap changes are required for the chmod issue.

[alexlarsson]

In general we try to avoid external dependencies as much as possible, and getting the gpg socket directory is pretty easy:
https://github.com/gpg/gnupg/blob/0904b8ef348a52335c378bee6dc90a978885d66f/common/homedir.c#L566
So, i would prefer if we hand roll similar code to find the directory rather than shelling out.

[alexlarsson]

I'm not an expert on GPG, so I have some questions:

• The extra socket sound like a good idea. Is this something that is generally available, or is does it need a very new version of gpg?
• What is the binary compatibility status for the agent protocol. Can we rely on it not changing?
• Are the gpg2 and gpg1 agents compatible?

[cmollekopf]

I'm not an expert on GPG, so I have some questions:

* The extra socket sound like a good idea. Is this something that is generally available, or is does it need a very new version of gpg?

* What is the binary compatibility status for the agent protocol. Can we rely on it not changing?

* Are the gpg2 and gpg1 agents compatible?

I'm not an expert either;

• I believe it is generally available in version 2.2 (before you had to add some extra confiugration for it), where also the location of the sockets changed from the home directory to /run/
• I don't think there are any guarantees about e.g. backwards compatibility.
• No idea, but I would not expect them to be.

To be honest, I'm also not sure if this is the best approach to solve this, but:

• The only alternative seems to invent an entirely new abstraction layer (or amend gpgme) that could proxy all requests to outside of the flatpak, which seems silly given the agent-protocol already covers everything functionality wise (and the extra abstraction just seems like a lot of work).
• Just running the gpg-agent inside the flatpak can't be a proper solution I think, because it won't work for things like hardware tokens I suppose. The pinentry issue (that you have to reenter the password on every application launch because new gpg-agent) can be worked around by relying on the existing support for libsecret (so the pinentry just uses libsecret as password cache).

I think I'll write a mail to the gpg mailinglist asking for some advice, as long as containers/bubblewrap#346 isn't fixed (or gpgme looses it's requirements) we anyways can't really ship this solution.

[SISheogorath]

About compatibility, the gpg agent is able to tell when the socket/server is completely different (which is the case when using centos7 on the host and fedora as client) and refuse to function.

Small version differences (e.g. patch versions) will produce a warning but from my experience work completely fine.