Re: Management of background services with systemd
On Thu, Mar 02, 2023 at 05:53:21PM +0100, Werner Koch via Gnupg-users wrote: > On Wed, 1 Mar 2023 21:24, Michael Richardson said: > > > Combined with SSH access to the machine, and the passphrase/pin popup shows > > up in the wrong place. > > Talking about ssh: Yes, you need to make sure that gpg-agent has been > launched. But once that has been done ssh works nicely. > > The major problem with ssh is that ssh has no way to pass environment > variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the > envvars to pop up pinentry on the right tty/display. I once posted > patches to the ssh list to extend ssh in this way but the interest was > not high and I had no time to starting convincing them to apply these > patches. > > Actually it would also be possible to tell ssh to autostart gpg-agent, > similar to what gpg does. This could be done as a generic pre-connect > extension to ssh. FWIW, there is also the keychain tool that may be invoked in shell startup scripts (which also provides the ability to differentiate - if needed - between interactive and non-interactive shells): - the tool itself: https://www.funtoo.org/Keychain - a couple of patches that we apply to the Debian packaging: - https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/malformed-ssh-key.patch - https://salsa.debian.org/debian/keychain/-/blob/debian/master/debian/patches/empty-ssh-askpass.patch G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd
On Wed, 1 Mar 2023 21:24, Michael Richardson said: > Combined with SSH access to the machine, and the passphrase/pin popup shows > up in the wrong place. Talking about ssh: Yes, you need to make sure that gpg-agent has been launched. But once that has been done ssh works nicely. The major problem with ssh is that ssh has no way to pass environment variables to gpg-agent via the ssh-agent protocol. gpg-agent needs the envvars to pop up pinentry on the right tty/display. I once posted patches to the ssh list to extend ssh in this way but the interest was not high and I had no time to starting convincing them to apply these patches. Actually it would also be possible to tell ssh to autostart gpg-agent, similar to what gpg does. This could be done as a generic pre-connect extension to ssh. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd
On Wed, Mar 01, 2023 at 09:24:35PM -0500, Michael Richardson wrote: > > David Joaquín Shourabi Porcel wrote: > > I am researching GnuPG for my employer. We will stick with the old > > release series 2.2 at first, because few Linux distributions package > > 2.3 or 2.4 yet. However, I'm studying newer versions and recent > > developments to ease our future upgrades. In doing so, a question has > > arisen: should background services like the agent not be managed with > > systemd? > > Please no. > > It's bad enough as it is when you have multiple personalities you are trying > to support (signing as me, vs signing code with an offline key)... having > systemd (the userland one) popping off new copies would be horrible. > > Combined with SSH access to the machine, and the passphrase/pin popup shows > up in the wrong place. > > (And many of us do not trust systemd and do not run it on important machines) Having systemd control gpg-agent can be a huge problem even with a single personality. If you want a user to login via ssh to start an agent to temporarily store a passphrase, and then the same user logs in separately via ssh to make use of it, systemd treats them as different user sessions, each with their own gpg-agent, and the second one has no access to the passphrase setup for it by the first one. Presumably, this isn't a problem for most use cases, but it really spoiled things for me. cheers, raf ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd
David Joaquín Shourabi Porcel wrote: > I am researching GnuPG for my employer. We will stick with the old > release series 2.2 at first, because few Linux distributions package > 2.3 or 2.4 yet. However, I'm studying newer versions and recent > developments to ease our future upgrades. In doing so, a question has > arisen: should background services like the agent not be managed with > systemd? Please no. It's bad enough as it is when you have multiple personalities you are trying to support (signing as me, vs signing code with an offline key)... having systemd (the userland one) popping off new copies would be horrible. Combined with SSH access to the machine, and the passphrase/pin popup shows up in the wrong place. (And many of us do not trust systemd and do not run it on important machines) signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Management of background services with systemd
On Thu, Mar 2, 2023 at 5:31 AM David Joaquín Shourabi Porcel wrote: > > //snip > > I have experienced only one limitation: there is no convenient way for > systemd to manage background processes for [ephemeral home directories][7], > which I have been using extensively for my research & testing. > So it would be helpful if someone steps up to add systemd interface, as long as it's cleanly decoupled from other parts of gnupg, so that no extra effort is necessary from other developers, and nothing is lost when gnupg is used on systems with service and log management interfaces other than systemd. > > [1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7 > [2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95 > [3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9 > [4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e > [5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed > [6]: https://dev.gnupg.org/T6336 > [7]: > https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html > > ___ > Gnupg-users mailing list > Gnupg-users@gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users Guan ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Management of background services with systemd
I am researching GnuPG for my employer. We will stick with the old release series 2.2 at first, because few Linux distributions package 2.3 or 2.4 yet. However, I'm studying newer versions and recent developments to ease our future upgrades. In doing so, a question has arisen: should background services like the agent not be managed with systemd? Daniel Kahn Gillmor [introduced][1] and maintained systemd unit files and also implemented `--supervised` for the [agent][2] and [dirmngr][3] as part of version 2.1.16. However, `--supervised` has been [deprecated][4] since version 2.3.6 and Werner recently [removed the systemd unit files][5] altogether. In fact, he commented the following on [task T6336][6] about two months ago: > Actually, the entire systemd based launching is deprecated and thus the > logged warning [about `--supervised`] is on purpose. > > The problem with the systemd launched gpg-agent is that it creates a race: > gpg launches gpg-agent as needed and to avoid concurrent launching by other > gpg or gpgsm processes, it takes a file system lock during the launch > process. systemd does not know about this and we end up with sometimes end up > with two gpg-agent processes. Eventually one of those processes detects that > it does not own the socket and terminates itself. No real harm here but you > may see smart card lockups or a flushed password cache. For what it's worth, the systemd setup (as packaged with series 2.2) works very well for me. In particular: - background services are managed through a common interface (that of systemd); - logs are centralized; and - the agent starts whenever OpenSSH needs it, thanks to socket activation. I have experienced only one limitation: there is no convenient way for systemd to manage background processes for [ephemeral home directories][7], which I have been using extensively for my research & testing. [1]: https://dev.gnupg.org/rG57e95f5413e21cfcb957af2346b292686a5647b7 [2]: https://dev.gnupg.org/rG9f92b62a51d2d60f038fdbe01602865c5933fa95 [3]: https://dev.gnupg.org/rG75f8aaf5bc2dc7fcffe2987a572d489155c91eb9 [4]: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e [5]: https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed [6]: https://dev.gnupg.org/T6336 [7]: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users