Page MenuHome GnuPG

Kleopatra: Unexpected comma separated keygrip for kyber certs
Testing, NormalPublic

Description

Kleopatra doesn't expect comma separated values for the keygrip of kyber certs, which might cause further issues.
I experienced some quirks already, but nothing reproducible/attributable so far.

After the generation of a kyber key, on refresh the debugview contains:

4	0.093634	4608	kleopatra.exe	org.kde.pim.libkleo: Cannot open the private key file "C:/Users/g10/AppData/Roaming/gnupg/private-keys-v1.d/6AC66D47CB7BFF7FAAA405A434CBEE7368EAE8BE,8DB4C49CBAF0F64B57146DA05E27C54E086DA2A7.key" for reading

The files in private-keys-v1.d/ are:

  • 6AC66D47CB7BFF7FAAA405A434CBEE7368EAE8BE.key
  • 8DB4C49CBAF0F64B57146DA05E27C54E086DA2A7.key

Details

Version
gpg4win-5.0.0-beta395 @ win11

Event Timeline

timegrid created this object with edit policy "Contributor (Project)".
TobiasFella triaged this task as Normal priority.
ikloecker changed the task status from Open to Testing.Wed, Oct 29, 3:57 PM
ikloecker moved this task from Backlog to WIP on the gpd5x board.

The API documentation of gpgme has been improved. And Kleopatra no longer tries to read the private key files of subkeys using combined algorithms (like Kyber+some curve) because (as of now) such keys are not stored on any smart cards (that are supported by GnuPG).

Kleopatra still shows the comma-separated keygrips for such subkeys (if the Keygrip column is enabled). I think that's okay (and it may even be useful for debugging).

I didn't see any other potential problems caused by the keygrip(s) of subkeys with combined algorithms in the source code. The keygrip is only used in combination with smart cards and for this comma-separated keygrips are no issue (as explained above).