{F1822230}This might be on the border line between a bug and an enhancement request. Retag if desired.

We have been hit by the gpg-agent ending up in somewhat of an inconsistent state after the homedir had been moved. This happens in our build process, but I've attached a transcript illustrating the problem in a simplified way in an attachment. What happens is essentially.

1. A GnuPG homedir is extracted from a tar file. This was created by an old GnuPG version, and thus contains a secring.gpg file with the secret keys.
2. When using this homedir, the secret keys are automatically migrated to a private-keys-v1.d subdirectory.
3. The homedir is moved to another name.
4. The original contents of the homedir is extracted again.
5. When using this new homedir, the agent will believe it is serving the new instance of the directory. Also, it uses inotify, and since the directory still exists, there hasn't been any notification. But the gpg client command will not see any migration, so it will try the migration again. This will fail, since the agent will try to write to the directory private-keys-v1.d inside the new copy of the directory, where no such directory exists.

The root of the problem is as I understand it that gpg-agent uses inode in one case but the path in another case. From my linux-only perspective it seems like a possible solution would be to.

1. Let gpg-agent do chdir() into the homedir. That way, it could use relative paths to everything inside, and not be dependent on the directory's position inside the full file tree.
2. Use a device-inode combination rather than the path to identify the gpg-agent inside /run/user/<uid>/gnupg. That way, the gpg client would not think the agent is serving the new copy of the directory, and instead start a new agent instance. Conversely a client that tried to use the old homedir under its new name would find the agent for it, and could avoid starting a second.

OS: Red Hat Enterprise Linux 8
GnuPG package: gnupg2-2.2.9-1.el8.x86_64