Open proninyaroslav opened 1 year ago
Fedora 37 (and all previous) ships incompatible pcsc-lite package with flatpak. You need to wait for F38 or somewhat install fixed pcsc-lite package.
More details: https://ludovicrousseau.blogspot.com/2022/02/fedora-flatpak-and-pcsc-lite.html https://github.com/flathub/com.yubico.yubioath/issues/35
I think I found the root cause: the DBUS_SESSION_BUS_ADDRESS
from within the flatpak leaks into the gpg-agent
's execution environment causing the pinentry to fail. I'll describe my situation top to bottom just in case there is a difference in expectations from the original bug report.
From within flatpak'ed Thunderbird, the gpg
executable should be able to communicate with the gpg-agent
which is running outside of the container. The agent should use the pinentry
executable from the host environment to unlock the smartcard or any password protected key. Using this mechanism, Thunderbird (and any other flatpak'ed gpg
consumer) should be able to use keys located outside of the flatpak. For instance, the following should succeed from within the flatpak:
$ gpg-connect-agent 'scd serialno' /bye
S SERIALNO SOMESERIALNO
OK
$ gpg-connect-agent 'scd checkpin SOMESERIALNO' /bye
OK
No pin entry prompt is presented to the user. When gpg
is run, a terse error about pinentry error
is given. The scenario described above is instead:
$ gpg-connect-agent 'scd serialno' /bye
S SERIALNO SOMESERIALNO
OK
$ gpg-connect-agent 'scd checkpin SOMESERIALNO' /bye
ERR 83886166 pinentry error <Pinentry>
As a workaround for the issue, I've created an executable which unsets the DBUS_SESSION_BUS_ADDRESS
. This seems to allow full functionality using the gpg-agent
from outside the flatpak:
$ cat >"$HOME/.var/app/org.mozilla.Thunderbird/.thunderbird/gpg-workaround.sh" <<'EOF'
#!/bin/sh
exec env -u DBUS_SESSION_BUS_ADDRESS gpg "$@"
EOF
$ chmod +x "$HOME/.var/app/org.mozilla.Thunderbird/.thunderbird/gpg-workaround.sh"
Thunderbird has to be additionally configured to use that executable instead of gpg
by assigning the config option mail.openpgp.alternative_gpg_path
to point to that executable as seen from inside the flatpak (i.e.: ~/.thunderbird/gpg-workaround.sh
).
I assume it is possible to keep that executable somewhere else. I simply knew that directory was already persisted for Thunderbird and didn't want to fight with flatpak permissions anymore.
@proninyaroslav , could you try this in your environment?
I think the solution is in gpg-connect-agent
or whatever performs that function internally to gpg
. It seems incorrect for the environment of the client to leak into the environment of the server. I think that is a discussion for the gpg
mailing lists rather than here though. Also, it seems like an uphill battle since this behavior is functional outside of this niche.
When I try to open an encrypted email, Thunderbird writes that the secret key was not found, although it is on the smart card and I configured everything according to the Thunderbird:OpenPGP:Smartcards instructions. Sockets
pcsc
,gpg-agent
are allowed, as well as~/.gnupg
,xdg-run/gnupg:ro
directories. OS: Fedora Linux 37.The log says that RNPLib found 5 public keys and 0 secret ones, although the smart card is inserted at this moment:
When I try to sign an email, I get an error and in the log I see the following: