[Discussion] Separate GPG between container and host

[irfanhakim-as]

Context

I am using SteamOS 3, and have been daily driving an Arch Linux distrobox container for all of my development work. For this discussion though, I believe what distro the container is running is irrelevant. My container was created with a custom $HOME directory, as I do not want to have configurations of both systems to clash when I do not want them to. Anything that I'm fine with sharing, I would just symlink them from the host's home directory to the container's.

Issue

My workplace enforces GPG signing for our git commits. At first, I simply set up my GPG key for GitHub on my host system, then symlinked the ~/.gnupg directory from the host to the container's. This initially worked as far as I can tell. I'm not too familiar with GPGs but I know they're important, so I don't really feel safe doing this and would prefer having them separate.

Recently though, I got the error WARNING: server 'gpg-agent' is older than us (2.2.40 < 2.2.41) when I tried signing my git commit from my container. This also happens if I remove the ~/.gnupg symlink and try to generate a new GPG key from my container with the command: gpg --full-gen-key. Upon checking, gpg is of version 2.2.41 on my container and 2.2.40 on my host system - which might be the cause of this issue.

I really love the idea of having an immutable system such as SteamOS 3 and using a distrobox container based on Arch for my work - getting through this hurdle would mean a lot. I'm familiar with containerisation such as Docker, etc. but after religiously reading Distrobox's wiki, I know they've done a lot more than that, and looking for a solution to this has left me at a loss. Google has never worked out for me too when it comes to Distrobox.

Desired Solution

Does anyone have a solution or pointer they can share on how I might be able to separate these two system's GPG setup to avoid version clashes like I think I am facing? Feel free to add in an alternative solution that you think might even be better.

I'm also curious as to how people get through this when they're using a host system based on distro A and a containerised system based on distro B - despite sharing some parts of the host's root directory. Surely, that'd bring up a variety of different issues I might not have encountered/thought of yet?

[luc14n0]

Hello there Irfan,

As a fellow distrobox user, I honestly don't think there's any separation to be done here. Let's try to understand together what WARNING: server 'gpg-agent' is older than us (2.2.40 < 2.2.41) warning is telling us.

First things first first, I can say it's worth your while trying to understand what gpg-agent is, in the first place, for that you can take a look at the description in its manpage. Since you're not familiar with GPG, only knowing that the "gpg-agent is a daemon to manage secret (private) keys independently from any protocol." should be enough for our discussion here.

gpg-agent can be run in two modes, as a daemon (gpg-agent --daemon) where it will run in the background; and as server (gpg-agent --server) that runs in the foreground. Usually, gpg-agent is automatically started and you don't have to worry about it.

Now, coming back to the WARNING: server 'gpg-agent' is older than us (2.2.40 < 2.2.41) warning. When you try to sign commits from the Arch container, Arch's GPG (version 2.2.41 at the time of the report) will invoke gpg-agent, but no more than one gpg-agent can be running at a time. And in your case the host's gpg-agent (version 2.2.40) was already running.

Since this was just a warning - and you didn't state whether it caused the commit signing to fail, I'm supposing it didn't -, and we're talking about a difference of only one point release (x.y.40 -> x.y.41), I wouldn't worry about this, personally.

However, if you really feel the need to use the container's gpg-agent instead of the host's, you just have to run it as a daemon. Yes, it should be simple like that. There's no need to create new keys either. You can check man gpg-agent for details on how to run it and even on how to automate the process if that's something you're interested.

[irfanhakim-as]

@luc14n0 thanks for the reply, this has been insightful and has given me the idea to check on some things but so far, i still have not been able to achieve my goal of signing git commits using gpg on my distrobox. The host system however, still does it perfectly fine.

Since this was just a warning - and you didn't state whether it caused the commit signing to fail, I'm supposing it didn't -, and we're talking about a difference of only one point release (x.y.40 -> x.y.41), I wouldn't worry about this, personally.

To clarify on this, this warning did indeed fail the commit signing and not just a warning.

Some things I tested on both my host system and distrobox. Based on these tests, I'm just not sure why or how it uses the gpg-agent on the host instead of running/using one on distrobox itself, and how to mitigate that considering it seems to not be able to use the host's properly (presumably due to clash in versions):

.gnupg home

Host

/home/deck/.gnupg

Distrobox

/home/foo/.gnupg

gpg, gpg-agent, and gpgconf --version

Host

gpg (GnuPG) 2.2.40
gpg-agent (GnuPG) 2.2.40
gpgconf (GnuPG) 2.2.40

Distrobox

gpg (GnuPG) 2.2.41
gpg-agent (GnuPG) 2.2.41
gpgconf (GnuPG) 2.2.41

which gpg, gpg-agent, and gpgconf

Host

/usr/bin/gpg
/usr/bin/gpg-agent
/usr/bin/gpgconf

Distrobox

/usr/bin/gpg
/usr/bin/gpg-agent
/usr/bin/gpgconf

Generating a GPG key on the distrobox

Output of running gpg-agent --daemon as per your recommendation

gpg-agent[11083]: directory '/home/foo/.gnupg' created
gpg-agent[11083]: directory '/home/foo/.gnupg/private-keys-v1.d' created
gpg-agent: a gpg-agent is already running - not starting a new one

Output of attempt to generate a gpg key using gpg --full-gen-key

gpg: WARNING: server 'gpg-agent' is older than us (2.2.40 < 2.2.41)
gpg: Note: Outdated servers may lack important security fixes.
gpg: Note: Use the command "gpgconf --kill all" to restart them.
gpg: agent_genkey failed: Timeout
Key generation failed: Timeout

[luc14n0]

Pay attention to the gpg-agent --daemon output: gpg-agent: a gpg-agent is already running - not starting a new one

As I pointed out, and the manpages states, only one agent can be running at a time! So, if there's one already running, first you need to kill it with gpgconf --kill gpg-agent and then you start a new one (gpg-agent --daemon) from the container.

Now, the last command seems to time out with:

gpg: agent_genkey failed: Timeout
Key generation failed: Timeout

In this case, I don't believe it's because of that warning. After passing gpg --full-gen-key, do you get any other output aside the one you posted?

[luc14n0]

By the way, some point I haven't touched in my previous comments.

Despite you feeling unsafe, I can't see how signing commits either in the host or in a container would impact security, but I'm no expert on the matter. Containers weren't made to be more secure in the first place.

I'm also curious as to how people get through this when they're using a host system based on distro A and a containerised system based on distro B - despite sharing some parts of the host's root directory. Surely, that'd bring up a variety of different issues I might not have encountered/thought of yet?

Yes, it would. Since distrobox is a nice wrapper for Docker/Podman, part of its job is to hide that complexity (those differences that Linux distros inherently have) from the user by dealing with it in sort of a case by case scenario.

[mcepl]

Pay attention to the gpg-agent --daemon output: gpg-agent: a gpg-agent is already running - not starting a new one

Currently, the upstream preferred solution for running gpg-agent is that it is run only when needed. However, that really doesn’t work with host-system+containers combination we run, because then gpg-agent tries to run inside various containers, where it either is not installed at all or one gpg-agent instance stands on the feet of the other one.

The only viable solution in my opinion is to run gpg-agent constantly on the host system, which was the previous-preferred solution by using user systemd sockets, and I have managed in https://bugzilla.suse.com/show_bug.cgi?id=1164872 to preserve these systemd unit files in openSUSE gpg2 package (see details of whole situation there). Obviously, when the gpg-agent is running, those sockets are available and gpg doesn’t have the need to start new gpg-agent.

See details of the configuration on Arch Linux wiki.

[denisok]

I bumped into the issue that pub key is seen inside container, but secret key is not.

gpg --list-keys returns puи key record, but gpg --list-secret-keys nothing. What is the right way to get secret key working inside of the container ?

Is that https://github.com/89luca89/distrobox/issues/1249 ?

looks like:

gpg-agent[30189]: DBG: chan_9 -> OK Pleased to meet you, process 30227
gpg-agent[30189]: DBG: chan_9 <- RESET
gpg-agent[30189]: DBG: chan_9 -> OK
gpg-agent[30189]: DBG: chan_9 <- OPTION ttyname=/dev/pts/0
gpg-agent[30189]: DBG: chan_9 -> OK
gpg-agent[30189]: DBG: chan_9 <- OPTION ttytype=alacritty
gpg-agent[30189]: DBG: chan_9 -> OK
gpg-agent[30189]: DBG: chan_9 <- OPTION display=:0
gpg-agent[30189]: DBG: chan_9 -> OK
gpg-agent[30189]: DBG: chan_9 <- OPTION xauthority=
gpg-agent[30189]: DBG: chan_9 -> ERR 67109140 IPC syntax error <GPG Agent> - option argument expected
gpg-agent[30189]: DBG: chan_9 <- BYE
gpg-agent[30189]: DBG: chan_9 -> OK closing connection

UPD: indeed #1249, this helped me:

unset XAUTHORITY
unset XAUTHLOCALHOSTNAME

[mcepl]

I am still holding on my solution and so far it works, but upstream claims it won’t with the next release, see more discussion in that thread, but I am not sure what is the proper solution for MicroOS-based Sway system.