Bug#993578: [pkg-gnupg-maint] Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Christoph Biedl]

Control: tags 993578 pending

Raphael Hertzog wrote...

> With the patch in https://salsa.debian.org/debian/gnupg2/-/merge_requests/9
> I no longer have this issue.

Thanks for preparing this.

> But I'm not sure if the patch is fully correct, the manual page is not
> clear whether --check-options foo is a subset of --check-programs. However
> the output format of both command is exactly the same.

Okay, so I mill do a close check of all components involved. Still it seems
your suggestion does more good than harm.

> BTW I believe this issue needs to be fixed in bullseye too.

ACK

Christoph, wading through the loong backlog.


signature.asc
Description: PGP signature

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Jonas Zeiger]

Hi,

I had this issue occur on several nodes running bullseye, where it severely 
affected operations (automated remote management).

The patch by Raphaël Hertzog looks great. Reviewed the patch and gpgconf source:
  - it should lead to gpgconf calling gc_component_check_options()
  - same as if using "gpgconf --check-programs", but for the "gpg-agent" 
backend only

I thought the bug could also be filed for/fixed in dirmgr:
 -> various login events
  -> systemd-environment-generator/90gpg-agent 
   -> gpgconf --check-programs
-> ...gc_component_check_options()
 -> dirmngr --gpgconf-test  // IMHO shouldn't perform blocking network IO, 
but does
  -> hang on TCP connect localhost:9050

Thus I checked the dirmngr source code and found this:

>  /* Note that we do not run set_tor_mode in --gpgconf-list mode
>   * because it will attempt to connect to the tor client and that can
>   * be time consuming.  */
>  post_option_parsing ();
>  if (cmd != aGPGConfTest && cmd != aGPGConfList && cmd != aGPGConfVersions)
>set_tor_mode (); 

This seems to be to be intended behavior for dirmngr and could be considered a 
feature.

I think many people are waiting for the updated "gpg-agent" package to arrive 
for stable (bullseye).

Kind regards,
Jonas

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Raphael Hertzog]

Control: severity -1 serious
Control: tags -1 + patch

Hello,

I have been bitten by this bug for multiple months without having a clue
of what was going on... when I resumed my laptop without wifi, the GNOME
session would be blocked for a minute or so.

With the patch in https://salsa.debian.org/debian/gnupg2/-/merge_requests/9
I no longer have this issue.

But I'm not sure if the patch is fully correct, the manual page is not
clear whether --check-options foo is a subset of --check-programs. However
the output format of both command is exactly the same.

BTW I believe this issue needs to be fixed in bullseye too.

Cheers,
-- 
Raphaël Hertzog

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Kévin Seroux]

Hello,

This bug happened to my server, it prevented SSH connections.

One workaround is to initiate another SSH connection before the session 
drop timeout (systemd seems to not trigger several times 90gpg-agent).

Since I removed the gpg-agent package, SSH now works.

Regards,

Kevin

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

[Ansgar]

Package: gpg-agent
Version: 2.2.27-2
Severity: normal
File: /usr/lib/systemd/user-environment-generators/90gpg-agent

The 90gpg-agent generator calls `gpgconf --check-programs` which calls
`dirmngr` which tries to connect to localhost:9050 (Tor) for some
reason.  This can hang, causing the generator to timeout (and thus the
systemd --user instance as well) and causing 90s delay for logins.

This issue was reported once a few days ago in #-devel (user
configured firewall to drop packets, even on the lo interface) and
today on #-systemd (not sure why connection to localhost:9050 did not
succeed, Tor should even be available).

The generator should avoid relying on network operations that
potentially hang/time out.

Ansgar