Description of problem: A fresh installation of Fedora 37 has by default the "--supervised" option active in its gpg-agent systemd file (/usr/lib/systemd/user/gpg-agent.service). According to GnuPG Docs [1], this option is deprecated. Once the gpg-agent is in systemd enabled and gets invoked (in my case with `pass`), the log of "systemctl --user status gpg-agent.service" confirms the issue with: "gpg-agent[2022]: WARNING: "--supervised" is a deprecated option" I cannot verify if this is intended for some reason. Off the cuff I do not see an immediate security issue, but I guess it makes sense to get over deprecated options. In the mailing list, it was noted that this service file is from upstream (GnuPG). So it should maybe get fixed there. See topic "Fedoras GnuPG default option is deprecated" in the devel mailing list: https://lists.fedoraproject.org/archives/search?mlist=devel%40lists.fedoraproject.org&q=Fedoras+GnuPG+default+option+is+deprecated Related: https://dev.gnupg.org/rGca5d5142c6d6eaba4572a086f8473e4aebdd3f9e [1] https://www.gnupg.org/documentation/manuals/gnupg/Agent-Commands.html Version-Release number of selected component (if applicable): Fedora 37 KDE; originally with GnuPG 2.3.7, after updating to 2.3.8, the file remains unchanged. So the deprecated option is still contained. How reproducible: -> Check `cat /usr/lib/systemd/user/gpg-agent.service` -> Test by: enable and invoke default gpg-agent.service. Then check its status with systemctl for the related warning log. I invoked gpg-agent with `pass`. Actual results: gpg-agent works, but it logs a warning about the deprecated option. Other implications or compatibility issues of the deprecated option are not known. I only tested it with `pass` in a default configuration within a VM. Expected results: gpg-agent works without warning / without deprecated option.
I filed https://dev.gnupg.org/T6336 upstream and attached a patch to remove the --supervised option from the example unit files. It may be sufficient to wait for that to be applied and then we can pick up the change on the next release.
It makes sense to fix the issue upstream and wait for it. It is nothing time critical. But if we adopt it only for the next release and keep the file as it is on F37, we have to ensure that the option remains available throughout the F37 life cycle, or ensure that the option is ignored if it gets removed from gnupg during that time. I cannot say much about GnuPG'S plans and practices in this respect. Since the tickets are already linked: a question that might be considered upstream is if the option should be just removed, or replaced by other option(s) or adjustments (generally, the behavior of "--supervised" makes sense for such a systemd service imho). Also, I am not sure if the current socket-based startup could cause trouble if the option is just removed: so maybe the related socket file needs adjustments, too. Not sure about further implications.
Sure. The upstream commit which marked them deprecated included no useful details about the problems caused (very unfortunately). If there are options which should be used instead, that's something the folks upstream will hopefully help in determining.
Thanks for taking this to upstream.
Commit related to https://dev.gnupg.org/T6336 -> https://dev.gnupg.org/rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed I think it makes sense to switch to managing via /etc/gnupg/gpg.conf in the medium term (see commit).
Out of curiosity, does anyone know what we'd put into /etc/gnupg/gpg.conf to provide similar functions as the systemd user units? Those unit files are gone in 2.4.1. I think our options are: * restore them via a patch (knowing they have race conditions and are unsupported upstream) * convert to global options in /etc/gnupg/gpg.conf (whatever that looks like) * drop support for the systemd units (which seems unlikely to be a good option for f38)
My suggestion would be to update only Fedora 39/rawhide with 2.4.1 and drop the systemd units in there. If upstream can not maintain them, I do not have capacity nor experience to maintain them downstream only. If either of you have a use for these and would like to to step up to maintain them, patches are welcomed. Todd already filled a PR for the changes so I will merge & build these later today unless there would be some strong voices against: https://src.fedoraproject.org/rpms/gnupg2/pull-request/16
The systemd services were dropped as part of the above PR so closing this bug too.
(In reply to Jakub Jelen from comment #8) > The systemd services were dropped as part of the above PR so closing this > bug too. I'm wondering if this perhaps needs a release note? This broke ssh for me and I'm perhaps using a gpg card for ssh-ing is not that uncommon: [lkundrak@frownland ~]$ ls -ld .config/systemd/user/sockets.target.wants/gpg-agent-ssh.socket lrwxrwxrwx. 1 lkundrak lkundrak 42 Apr 18 21:55 .config/systemd/user/sockets.target.wants/gpg-agent-ssh.socket -> /usr/lib/systemd/user/gpg-agent-ssh.socket [lkundrak@frownland ~]$
Opened https://pagure.io/fedora-docs/release-notes/issue/1029
FEDORA-2023-dbf507a4a5 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-dbf507a4a5
FEDORA-2023-dbf507a4a5 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-dbf507a4a5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-dbf507a4a5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-dbf507a4a5 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.