Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Gpg agent support #3446

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

WIP: Gpg agent support #3446

wants to merge 2 commits into from

Conversation

cmollekopf
Copy link

@cmollekopf cmollekopf commented Mar 5, 2020

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.

BrainBlasted and others added 2 commits Mar 5, 2020
Creates a --socket flag that allows access to the host
gpg-agent.

Related to flatpak#2301
@cmollekopf cmollekopf changed the title Gpg agent support WIP: Gpg agent support Mar 5, 2020
@rh-atomic-bot
Copy link

rh-atomic-bot commented Mar 5, 2020

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
Copy link
Author

cmollekopf commented Mar 7, 2020

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

flatpak_bwrap_add_args (bwrap,
"--ro-bind", agent_socket, sandbox_agent_socket,
NULL);
}
Copy link
Member

@alexlarsson alexlarsson Mar 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

alexlarsson commented Mar 16, 2020

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
Copy link
Author

cmollekopf commented Mar 21, 2020

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
Copy link

SISheogorath commented Dec 29, 2020

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.

@Erick555 Erick555 mentioned this pull request Jun 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants