GnuPG fails to sign after update and SSL provider switch.

[mschilli]

Hello there.

Let me start by admitting it:I did not treat my Gentoo box well. That is I did not update in months. I finally found the time to take on that dauntig task.
Besides the massive backlog of updates that I accumulated, I was also running a LibreSSL based system that I decided to switch over to OpenSLL in the light of recent events.
Portage did not figure out everything on its own as advertized in the news item, I assume mainly because there where a couple of blockers and I did not care updating first and switching from a clean state.
However, I got rid of LibreSSL, dropped in OpenSSL instead, rebuild wget, iputils, python and then resolved blocks until @preserved-rebuild finished. From there I escalated to --newuse --deep @world, again resolving a block or two along the way. Finally, I ran --update --deep @world followed by another @preserved-rebuild and the obligatory --depclean.

After a reboot, everything seemed fine, until I tried to make a git commit and it failed because GPG couldn't sign the data.
I quickly realized that git was not to blame: A simple

Code: Select all

gpg --clearsign <<<  test

fails.
It did work before and I did no change any settings. If I unset GPG_TTY I get the expected 'Inappropriate ioctl for device' error.
With GPG_TTY properly set however, I do get prompted for the passphrase for the (correct) secret key via pinentry. If I (deliberately) enter a wrong passphrase, I get the expected 'Bad Passphrase' error and two more tries. If I wait too long, pinentry closes and gpg fails with the expected 'Timeout' error. If, however, I enter the correct passphrase, gpg fails with an 'End of file' error.

Along the update process described above, I updated app-crypt/gnupg from 2.2.20-r1 to 2.2.25, app-crypt/pinentry remained at 1.1.0-r3 but was re-build.

At first I suspected some breakage related to the SSL provider switch, so I went through an emerge --oneshot --emptytree app-crypt/gnupg which did not help.
That included dbus and elogind which might be of interest since I don't run systemd and the only hint I could find regarding gpg failing with end of fle was this side note in the infamous Arch Wiki.

I did check loginctl list-sessions and I have a valid session there. Also I assume I had bigger issues than gpg complaining if my update screwed with my login session setup.

The point is that I have no clue how to go about that. I'd love to downgrade app-crypt/gnupg to see if the old version build against OpenSSL works but there are no ebuilds for =app-crypt/gnupg-2.2.20-r1 in the tree anymore.
Besides that, gpg appears to be working: I can list my keys etc just fine.
But I can't use them anymore and I kinda need to be able to sign things to use this system.

So If anyone has some idea how to further troubleshoot this situation, I'd be very happy to hear it.

Thank you in advance for you help and have a great day!

[mike155]

How do you start gpg-agent? Do you start it at all?

What happens if you start 'pinentry' manually? You should get a prompt. Enter 'GETPIN'. A window should open which asks you for a PIN. Enter a random value and press Enter. The value you entered should be returned with a leading 'D'.

Code: Select all

$ pinentry
OK Pleased to meet you
GETPIN
D my_secret_PIN
OK
bye
OK closing connection

Does that work?

[mschilli]

How do you start gpg-agent? Do you start it at all?

I don't (actively), since I never did (knowingly, that is) and it 'just worked' (tm).

Code: Select all

pgrep gpg

came back empty.

Code: Select all

eval $(gpg-agent)

failed with 'no gpg-agent running in this session'.

Code: Select all

gpg-agent --daemon

did not error but did not change any of the symptoms either:

Code: Select all

gpg --clearsign <<< test

still fails with 'End of file',

Code: Select all

eval $(gpg-agent)

still fails with 'no gpg-agent running in this session', and even

Code: Select all

pgrep gpg

remains empty.

What happens if you start 'pinentry' manually? You should get a prompt. Enter 'GETPIN'. A window should open which asks you for a PIN. Enter a random value and press Enter. The value you entered should be returned with a leading 'D'.

Code: Select all

$ pinentry
OK Pleased to meet you
GETPIN
D my_secret_PIN
OK
bye
OK closing connection

Does that work?

Like a charm.

---
edit:
I just tried

Code: Select all

eval $(gpg-agent --daemon)

and while this results in

Code: Select all

pgrep gpg

returning a PID,

Code: Select all

gpg --clearsign <<< test

still fails with 'End of file'.

[mschilli]

I have another major update:

Signing still does work after I generate a new keypair with standard settings and use that one.
So either there is an issue with my default key itself or with ed25519 signing keys.

I'll keep investigating.

---
edit (1):
I generated a new ed25519 sign-only key and I can clear-sign with it.

I am at a loss since I am running out of reasons to blame anything but my key files that just happend to get corrupted during a reboot after a massive update?

---
edit (2):
Actually I can rule out the file corruption hypothesis since I have another user on that system with the same key on its ring and it fails signing there as well.
So there must be something about that key that makes gpg choke.
The only differences to the working one I can see are that my default key has an expiration date and a comment set while the new one does not.

---
edit (3):
Another piece of evidence is that running gpg a second time, it does not ask for the passphrase via pinentry but goes straight to the error.
That tells me 'unlocking' the key works so it is probably fine but really for some reason the signing fails with one key but not the other.


---
edit (4):
Just in case I generated a new key with expiration date and comment and it still works. I compared the keys down to comparing ther preferences via showpref and they match.
I could successfully change the passphrase for my default key but it still won't sign.

[mschilli]

Just a heads-up: Since I did not hear anything back and my Gentoo system is basically unusable for its intended purpose for weeks now, I cross-posted this on StackExchange in case a non-Gentoo GnuPG user has some ideas.

I'll update and close this thread if anything comes up there.
I'd still appreciate any feedback via either of the two channels.