Change Details

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. # 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. # When using this //homedir//, the secret keys are automatically migrated to a `private-keys-v1.d `subdirectory. # The //homedir// is moved to another name. # The original contents of the //homedir// is extracted again. # 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. # 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. # 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

{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. # 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. # When using this //homedir//, the secret keys are automatically migrated to a `private-keys-v1.d `subdirectory. # The //homedir// is moved to another name. # The original contents of the //homedir// is extracted again. # 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. # 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. # 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

{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. # 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. # When using this //homedir//, the secret keys are automatically migrated to a `private-keys-v1.d `subdirectory. # The //homedir// is moved to another name. # The original contents of the //homedir// is extracted again. # 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. # 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. # 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