(In reply to Chris Denice from comment #0)


> "gpg-agent is a daemon to manage secret (private) keys independently from
> any protocol. It is used as a backend for gpg and gpgsm as well as for a
> couple of other utilities.
> 
> The agent is automatically started on demand by gpg, gpgsm, gpgconf, or
> gpg-connect-agent. Thus there is no reason to start it manually."
> 
> I am not an expert about the usage of gpg-agent, but if there is not
> objection I would either nuke these two scripts from the package, or more
> gently change the configuration file in /etc/sysconfig/gnupg2 to have


I am not too sure about removing the scripts. I do know disabling Kwallet in the kde configuration menu stops it from being launched.

CC: (none) => junknospam

Sure, we should test before.

For instance, we should check that if you switch:
START_GPGAGENT="no"
START_GPGAGENT_SH="no"

in /etc/sysconfig/gnupg2

and restart from scratch, applications using gpg-agent should be able to start it by themselves. If someone tests this, please report here if this work or not!

Another side effects of this bug is that systemd never detects idle time; setting 
IdleAction=suspend
IdleActionSec=30min

in /etc/systemd/logind.conf

never suspend the system as gnupg-agent maintains opened sessions even with logged out users. Once these gnupg-agent processes are killed by hand; the system suspends as it should.

Any update on that bug ?

CC: (none) => ennael1

Up to the testing I have done, the following settings in /etc/sysconfig/gnupg2

START_GPGAGENT="no"
START_GPGAGENT_SH="no"

prevent it to start all the time. But that does not fix the issue; as gpg-agent is indeed triggered sometimes by various programs; and never stops afterwards.

The same happens with ssh-agent (which is triggered by opening a ssh session if gpg-agent is not already running).

ssh-agent could be fixed by appending the -t option which gives a timeout delay after which it shuts down. For gpg-agent, I did not find any solution :-/

gpg-agent is started like this so that all terminals and programs can use it (environment variable is shared for all programs in that session).

Colin, thoughts?

CC: (none) => mageia, olav

Well, these days the comms sockets used by gpg (and ssh) agents could be standardised in /run/user/$UID/ folder and thus not need any direct env vars (the paths could be baked into any client programs).

Then those socket paths could have systemd (user) units and then be made socket activatable and have the timeout option to kill themselves after inactivity.

This would be the best plan going forward but it'll take some time to achieve this.

As a transitional phase we could:

1. Add the env var to a drop in file in /usr/lib/systemd/system/user@.service.d/gpg-agent.conf (and ssh-agent.conf) with:

[Service]
Environment=GPG_AGENT_INFO=/run/user/%I/gpg-agent

Then teach gpg-agent to accept a socket path as an argument and be socket activatable (will need patching).

Then write appropriate systemd user units that will live in /usr/lib/systemd/user/gpg-agent.{socket,service}


The patches should be fairly simple (someone may have written them already) and we can then kill off all the other methods of starting.

I may have missed some corner case of course, but I think this make sense going forward.

Colin, any input on this one? were you able to commit those patches ?

Up to the fact that this bug moved some dirt from under to over the carpet; it will be directly affecting only a few users using automatic suspend and/or machine having a lot of connected users.

Maybe that is fine to remove the release critical tag if we mention it in the mga5 errata, and we may target mga6 for a complete carpet hoovering?

Yeah I think we can remove this. It's already an issue under MGA4 anyway, so no worse than before :)

In MGA6 we will likely switch to a user bus, have predicable paths for SSH/GPG agent sockets and can teach them to exit after idle time outs (and be socket activatable). This will make things much nicer generally.

Hope the bug changes are agreed with (it would be nice to fix now, but sadly too much to do generally before MGA5 :()

Severity: critical => normal
Assignee: bugsquad => mageia
Priority: release_blocker => High

Arch has a unit file for this. It is bit nasty in that it just kills any gpg-agent when it should stop.

https://wiki.archlinux.org/index.php/GnuPG#Start_gpg-agent_with_systemd_user

Thanks for the info Olav.

I am starting to look at it in order to migrate both ssh-agent and gpg-agent to systemd user services. If anyone has some comments or other links to read, please post-it here, I am in Terra-incognita :)

Cheers.

Just pushed gnupg2-2.0.30-3.mga6 on Cauldron which is only based on systemd --user service.

It seems to behave nicely, switches on with pam systemd settings, i.e. on login and X, but not on remote ssh. It also switches off when the user logs out and the associated session can now close.

This is not yet the end of the story as the same would need to be done for ssh-agent. Also some work has to be done on keychain as, currently, it can trigger gpg-agent and ssh-agent from /etc/profile.d. I'll have a look as soon as I can. In the meanwhile, please report here if gnupg-agent fails.

Cheers,
Chris.

(In reply to Chris Denice from comment #13)
> Just pushed gnupg2-2.0.30-3.mga6 on Cauldron which is only based on systemd
> --user service.
> 
> It seems to behave nicely, switches on with pam systemd settings, i.e. on
> login and X, but not on remote ssh. It also switches off when the user logs
> out and the associated session can now close.

Excellent! I've been hoping this would happen sooner rather than later! Excellent work!

> This is not yet the end of the story as the same would need to be done for
> ssh-agent. Also some work has to be done on keychain as, currently, it can
> trigger gpg-agent and ssh-agent from /etc/profile.d. I'll have a look as
> soon as I can. In the meanwhile, please report here if gnupg-agent fails.

Brilliant! Thanks so much!

Thanks Colin :)
Well, to be honest, it is not yet as perfect as it sounds because I did not (yet?) implement activation sockets within systemd as you suggested.

gnupg still uses his old school sockets, but now under the supervision of a --user .service, and thus inherited systemd pam, so at least it is properly killed and started when it should!

What is the status of this bug report? Did everything that needed to get fixed, get fixed? (Or can it be closed as fixed for one part, and the rest moved to a new bug report)

CC: (none) => marja11

Yes, that bug is fixed, I am closing it. I am having a look to potential side issues with ssh-agent and now and will open new bug reports if necessary!

Status: NEW => RESOLVED
Resolution: (none) => FIXED