Note to self: T6100: Kleopatra: Make revocation of certifications accessible may be obsolete when the improvements are completed because then the dialog will most likely be gone.

If the user cannot revoke any of the certifications of the selected key or user IDs, then we now inform the user about this instead of showing the dilaog.

Firefox nicely shows the 3 NIST certificates from my Telesec card but not the important Brainpool certificate for eIDAS. It turns out that Firefox does not support Brainpool, despite that a patch has been provided 8 years ago. See https://bugzilla.mozilla.org/show_bug.cgi?id=943639 . Thus there is currently no way to use LibreOffice or Okular to signe PDFs because they rely on NSS.

We now propose "<fingerprint>.rev" in the last used export directory as file name. This is the same file name as for the revocation certificates that gpg automatically writes to the openpgp-revocs.d folder when a new OpenPGP key is generated.

The SEGV was due to access to gpgme library after self.wrapped is set to None in the __del__ function.

The commit is: rMb2f224a471fe: python: Reset passphrase callback correctly..

Thank you for the patch. You are right.

I have kept a backup copy of a WKDRefreshJob locally. ;-) But that's stuff for a different task.

Thanks, the update button this is now more what I think is expected. Still I am not sure if removing it completely was neccessary, well we have it in the history now. Because I see the need to also update via WKD. Currently we only update from there if a key is expired but we would never see revocations. That is a problem that we will need some solution for at some point. But yeah in that case calling it "RefreshOpenPGPKeysJob" would be a misleading API Name anyhow. So its probably good that you removed it before the upcoming release.

Still, the first thing you should do is to update to a recent version, the version you are on is about 3 years old. See https://gpg4win.org for the most recent version. Then add --verbose and --debug ipc to your command so we can maybe see more what it does.

Looks good. After entering a wrong passphrase three times Kleopatra now reports

Moving the key to the card failed: Bad passphrase

Please reopen my issue. This is a serious issue that we encounter and do not have any explication.

Hi!
No, it's not waiting for the password. This was a 2 times error happening on our server.
We already provided the password but it was hung. We entered different things but it won't make anything.
I can tell you it doesn't wait for anything because we tested the same command on 2 different machines. On one machine it was hung, on another it worked.

gpg was waiting for the passphrase for the signing key to be provided via stdin.

See T5903: Kleopatra: Add refresh button in certificatedetails for the corresponding Kleopatra task. Kleopatra now uses the good old ReceiveKeysJob for doing a key refresh from the configured key server. The RefreshOpenPGPKeysJob has been removed.

For an OpenPGP key, Update now performs a simple "retrieve key" operation for the existing key, i.e. it refreshes the key with the public key found on the configured key server.

With my patch I see the expected status message:

The problem seems to be that we don't return a status code with the
actual error via the --command-fd interface:

@gniibe Perfect, I got the update during the night actually. Thanks a lot for your work 🙏 .

For the firmware 5.4.3, I confirmed that it works well with the changes:
https://dev.gnupg.org/T6070#160150

Did you restart Kleopatra after enabling the high contrast mode? I have implemented that Kleopatra doesn't change/set any background or foreground colors if high contrast mode is detected. Maybe the detection (in SystemInfo::isHighContrastModeActive) doesn't work.

All issues were addressed.

Hi lovely people,

I thought "Update" would do a key server refresh by fingerprint. Maybe I looked at the wrong job? In testing we noticed this because we suddenly had additional keys after using "update". "Update" in the certificate details should only search by fingerprint. Maybe when we know that the key source is WKD we could also look by mail address?

Most things look good to me, it was automatically enabled when I switched Windows to high contrast mode. The only thing I noticed is that the fields where we explicitly set the background may not look to readable. Especially the Sign&Encrypt buttons because there we don't set the text color.

Okay. I do a KeyListJob with key list mode GpgME::LocateExternal which does the equivalent of --locate-external-keys and that depends on the auto-key-locate mechanisms which could include keyserver and other mechanisms besides WKD.

The lookup by email address is supposed to be done via WKD. Obviously, a lookup by fingerprint wouldn't work. And yes, obviously this may import additional key via WKD.

I am reopening this as the current behavior is strange in my opinion and should be changed before a release.
Currently the refreshopenpgpkeysjob does not refresh the OpenPGP Key by fingerprint but instead imports all keys with a similar e-mail address. This does not work for keys with no email. Also in case of public keyservers it can pull in keys that not belong to the user or are expired and so on.

@gniibe thanks for help.