Page MenuHome GnuPG
Create Task
Maniphest T7437

Kleopatra: Remove explicit start of gpg-agent on startup
Closed, InvalidPublic
Actions

Description

Especially on Windows we seem to have a problem if multiple processes race to start gpg-agent (e.g. T7434: Kleopatra: Initial keylisting hangs for ~60 seconds (gpg-agent: Socket ...S.gpg-agent cannot be bound)).

The explicit start of gpg-agent was added to address the problem that Kleopatra couldn't access smartcards if the user has an empty keyring because in this case neither gpg nor gpgsm start gpg-agent when doing a keylisting, so that no gpg-agent was running (rKLEOPATRAa365ef17e97eca1e3a4bc5f0cc833f3f48b1c2bb).

Nowadays gpg-agent is started if we want to make an Assuan transaction, so that the original reason for starting gpg-agent on startup doesn't exist anymore.

Related Objects
Search...

Event Timeline

• ikloecker created this task.Dec 4 2024, 11:20 AM
• werner added a comment.Tue, Dec 10, 2:54 PM

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

• ikloecker added a comment.Tue, Dec 10, 5:28 PM
In T7437#195688, @werner wrote:

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

Correct. There shouldn't be a problem. But the observations in T7434 show that there is a problem. The locking seems to work (gpg and gpgsm both wait for the gnupg_spawn_agent_sentinel.lock), but it seems the lock isn't released by the gpg-agent which fails to start because it cannot bind the socket.

• aheinecke added a subscriber: • aheinecke.Wed, Dec 11, 6:06 AM

I agree here with Werner. Changing the fronted to workaround locking / timing issues in the backend like in T4505: SM, W32: GPGSM hangs up the GnuPG System T6323: Kleopatra: Import multiple certificate files one after the other might be necessary in the short term to make a release possible. But even if, like in T6323 the code which avoids the issue is better this should rather be the last resort or done after doing a fix in the backend or to avoid the issue with older versions. I just wanted to comment because I clearly remember that in T6323 I was very glad to finally have a way to reproduce a deadlock with a high probability and then very frustrated that the issue was left in the backend and only hidden in Kleo.

• aheinecke mentioned this in T7434: Kleopatra: Initial keylisting hangs for ~60 seconds (gpg-agent: Socket ...S.gpg-agent cannot be bound).Wed, Dec 11, 7:53 AM
• ebo closed this task as Invalid.Wed, Dec 11, 2:04 PM
• ebo added a subscriber: • ebo.

There is consensus that the issue T7434 must be resolved in the backend, where it originates.