GPG Support stopps working from time to time

[Jacalz]

This issue tracker is intended only for Silverblue specific issues. We would like to ask you to try to reproduce the issue on a relevant Fedora Workstation release. If you will be able to reproduce there, then please report it in Red Hat Bugzilla (see How to file a bug) or in upstream (preferred for GNOME projects) and not in this issue tracker.

Describe the bug A clear and concise description of what the bug is.

GPG just occasionally stops working sometimes and it is very annoying. I haven't experienced the same error on Fedora Workstation before. I have git set up to GPG sign my commits but from time to time it fails with this error (the {keyid} field contained an ID in the original message):

error: gpg failed to sign the data:
[GNUPG:] KEY_CONSIDERED {keyid} 2
[GNUPG:] BEGIN_SIGNING H10
gpg: signing failed: No pinentry
[GNUPG:] FAILURE sign 67108949
gpg: signing failed: No pinentry

fatal: failed to write commit object

This is very annoying; especially when I commit from the terminal and my long and fancy commit message gets lost in space. The fix I have is to run gpgconf --kill all && gpg --card-status && gpg-agent on the host terminal (and not inside a toolbox container because that doesn't change anything for some reason). That makes GPG start working again (inside and outside of toolbox containers) for a few hours usually.

To Reproduce Please describe the steps needed to reproduce the bug:

1. Set up Git to GPG sign commits using steps on GitHub (https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key).
2. Sign the commit.
3. Notice that it usually fails.

For reference, this is what my setup script does for GPG setup:

gpg --full-generate-key
KEYID=$(gpg --list-secret-keys --keyid-format=long | rg -o "ed25519/(\d|\w){16}" | cut -b 9-)
git config --global user.signingkey $KEYID
git config --global commit.gpgsign true
gpg --armor --export $KEYID > GPGKEY.txt

Expected behavior A clear and concise description of what you expected to happen.

GPG should not fail randomly.

Screenshots If applicable, add screenshots to help explain your problem.

n/a

OS version:

State: idle
BootedDeployment:
● fedora:fedora/39/x86_64/silverblue
                  Version: 39.20231123.0 (2023-11-23T00:51:59Z)
               BaseCommit: e12cc578fbff10dc44570cd542b25f2ce9f6c61ea1b553dcd4cc71f0ac5b14a5
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
          LayeredPackages: ffmpeg-free fish gstreamer1-plugin-openh264 langpacks-en_GB
                           libavcodec-freeworld libva-intel-driver mozilla-openh264
            LocalPackages: rpmfusion-free-release-39-0.2.noarch

Additional context Add any other context about the problem here.

[travier]

How are you running your GPG agent? You should probably make sure it runs outside of the toolbox as a systemd user unit.

[Jacalz]

What I do is that I set up my GPG key like described above. Once I do my first signing of a commit, Gnome pops up a dialog asking for the password to unlock my key. I enter my password and check the checkbox that says that I want my key to be unlocked automatically when I log in to my account.

This workflow has worked fine on my previous installation of Fedora Workstation (on this computer and my main laptop) and I think my other Silverblue laptop is experiencing the same problem as described above.

For what it's worth, I was having this same issue on Fedora Silverblue 38 as well. Didn't report it then as it was quite a recent install and I was hoping that the update to 39 would fix it.

[travier]

I enter my password and check the checkbox that says that I want my key to be unlocked automatically when I log in to my account.

I don't know what this does.

[Jacalz]

I presume that Gnome automatically starts gpg-agent on login and automatically unlocks the key. I basically never have to enter my password for the GPG key.

[Jacalz]

It seems like this usually happens after the computer has been restarted. Perhaps the gpg-agent fails to start or Gnome fails to unlock it?

[comminutus]

The same thing happens to me on 3 different Silverblue 38 and Silverblue 39 deployments.

[Jacalz]

Same thing here still. I have to run my gpgfix alias command (alias gpgfix="gpgconf --kill all && gpg --card-status && gpg-agent") each time I restart my computer and sometimes again when I have had it running for a long time.

[comminutus]

mine is similar (bash function):

     pkill scdaemon
     pkill gpg-agent
     gpg-connect-agent /bye >/dev/null 2>&1
     gpg-connect-agent updatestartuptty /bye >/dev/null 2>&1
     gpgconf --reload gpg-agent

[Jacalz]

If anyone else is running fish and having this issue, this is my config (~/.config/fish/config.fish) to set up a gpgfix alias when running an interactive terminal and run the gpfix command automatically in the login shell so I don't have to do it each time I log in:

if status is-interactive
    # Commands to run in interactive sessions can go here
    alias gpgfix="gpgconf --kill all && gpg --card-status && gpg-agent"
    alias box="toolbox enter"
else
    gpgconf --kill all && gpg --card-status && gpg-agent
end

This more or less works around my issue for now but I still can't quite recommend Silverblue to anyone while this is still an issue. My development laptop will have to run Workstation for now as well.

[travier]

Does https://discussion.fedoraproject.org/t/gpg-hang-on-fedora-silverblue-39/103262/4 help?

[comminutus]

@travier I doubt it, that common.conf file referenced doesn't exist in my deployment other than in examples directories.

[travier]

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html

[comminutus]

@travier I thought the solution mentioned at https://discussion.fedoraproject.org/t/gpg-hang-on-fedora-silverblue-39/103262 was to comment out the use-keyboxd option.

What good would placing a common.conf file at ~/.gnupg/common.conf with a commented out use-keyboxd option do?

[Jacalz]

I don't have the file on my system either. Seems like it won't help our use case unfortunately