search

rpm-software-management / librepo

A library providing C and Python (libcURL like) API for downloading packages and linux repository metadata in rpm-md format
http://rpm-software-management.github.io/librepo/
GNU Lesser General Public License v2.1
75 stars 91 forks source link

More considerate approach to spawning gpg-agent #186

Open jnpkrn opened 4 years ago

jnpkrn commented 4 years ago

Not exactly sure how, I ended up in a state where there is gpg-agent process running in my user's session (the parent is the user instance of systemd, /usr/lib/systemd/systemd --user) and without regaining superuser privileges agains, there's exactly zero of things I can do about it, since it's an UID=0 process. It's basically this very observation:

https://www.reddit.com/r/Fedora/comments/4t90bk/i_found_someting_strange_about_gpg/

although I am at least reasonably sure no dnf nor rpm process is concurrently running in my case.

Commonly, I log in as my user on VT first, then su -c, then run the update, if not too intrusive, I continue to start a graphical session. That might explain the current process parent, otherwise it would be PID 1.

It doesn't explain, however, why this process keeps running when there is no dnf/rpm business going on, nor why it is needed to begin with ... is it to speed up verifications thanks to some caching? I play a dumb asker since there's hardly any actual signing going -- the main reason for such an agent in place, correct?

Personally, I'd prefer as little complexity, incl. spawning as little external programs, as possible. But I may be missing something.

At the very least, gpg-agent shall be exited the moment it's not longer actively used?

Thanks!

jnpkrn commented 4 years ago

Note that with this alleged misbehaviour, problems keep chaining in hard to anticipate ways!

For instance, for my terminal purposes, I am using urxvt256c-mld for which I've written a user service file, hence the whole scope underneath incl. each separate urxvt256c-ml terminal window and, of course, every command running in these terminals is suddenly of close interest by the user instance of systemd -- and it seems not be able (or willing) to kill foreign/UID=0 process on its own.

Which leads to one example pf problem chaining, for UID=0 gpg-agent not getting terminated properly at dnf finalization -- when this dnf command was run with terminal in the described arrangement.

lukash commented 4 years ago

This won't be very helpful but...

gpg (in particular gpgme) is used to verify signatures (of e.g. repository metadata, maybe more). This doesn't actually involve working with secrets so the gpg agent is not necessary for this, but gpgme needs it anyway and spawns it. There is a whole heap of issues with this and we would very much like to not have this happening at all.

But at the moment (as far as we know) there is no other usable gpg implementation that we could use, as this is about security, the requirements are also more strict.

I think the gpg agent is supposed to terminate after it is spawned by gpgme, but don't quote me on this, I am actually not sure. It is also dependent on the environment, maybe in your setup, which seems to be quite customized, it behaves weird. That wouldn't be too surprising...

Attempting to replace the gpg implementation with something better is planned, but not in the near future... Sorry, I don't think we can help more with this :frowning_face: