Looks good to me on gpg4win-5.1.0-beta658 @ win11.

Looks good to me on gpg4win-5.1.0-beta658 @ win11:

Looks good to me on gpg4win-5.1.0-beta658 @ win11:

This issue would now be about adding a hint to the audit log for a full list of recipients, in S/MIME decryption feedback in Kleopatra.
But besides the amount of recipients, this list only shows the root certificates of the other ones:

In T8334#220258, @pl13 wrote:

The test certificates do not have a crlDP, so there is no crl check done and no dirmngr is called for this.

Patch up in https://invent.kde.org/graphics/okular/-/merge_requests/1414 that removes the finish ('cause it will not work) when reloading

Well at least the reporter was of the opinion that it worked. Depends on what one expects.

Looks good to me on gpg4win-5.1.0-beta658 @ win11.

Looks beautiful to me on gpg4win-5.1.0-beta658 @ win11

Issue Found

• Details
  • Table size is still 3 rows for OpenPGP certificates (fix only works for S/MIME)
    
    

Looks good to me on gpg4win-5.1.0-beta658 @ win11:

I don't know what you understand as "does work". For single files two completely separate things are done:

1. A detached S/MIME signature for the unencrypted file is created.
2. The unencrypted file is S/MIME encrypted.

Public key will not happen. It might also get removed from NSS backend.

The test certificates do not have a crlDP, so there is no crl check done and no dirmngr is called for this. (see here)
After repeating the command the issuer is looked up from the dirmngr cache. In this test case the dirmngr is not called for a crl check but for a lookup.

I tested gpgmeqt's AD query job with beta gpg4win-5.1.0-beta646 on WIN10 (with qgpgme version 2.1.0) and an AD-user:

Moreover, for S/MIME, it will disable "combined" sign and encrypt.

This happens only, if the Kleopatra main window is open and behind Okular.

If this is only a visual cutoff/fadeout, and the content still is still displayed, after the width was adjusted.

Ah, well, the window with can obviously be changed, so a cutoff/fadeout would be fine.

A cutoff/fadeout could be problematic, if you have multiple certificates you have to distinguish.
There is some information available in the tooltip, but it might be missing some (no email in this example):

I guess cutting it off / fading it out is the only sane way of dealing with infinite long uid's ?

I think this need to be handled by Kleo ? @ikloecker

In T8018#220049, @svuorela wrote:

whattabout https://invent.kde.org/graphics/okular/-/merge_requests/1404 ?

In T6632#220019, @timegrid wrote:

Note: the "qualified" tag overlaps long uids (I'll create another ticket for that):

Note: The Kleopatra window is often opened behind the other windows, and you think it does not work, so you click again and another hidden window opens. It would be nice, If this could be fixed (will create another issue for it)

In T8018#219988, @ebo wrote:

seems to me, that the details here are no details and could be dropped completely. I'm i overlooking something?
And wouldn't "Could not sign: Wrong passphrase" be better? Or even better: "Signature failed: Wrong passphrase"?
In Kleopatra we have: "Signing failed: %1"

The easiest fix is to enable the "exclusive" mode that we use for the notepad (and the clipboard) also for the Sign/Encrypt Files/Folder dialog. This will disable mixing of OpenPGP and S/MIME recipients (which is anyway misleading because in case of encryption the result is two separate encrypted files with mutually exclusive recipients). Moreover, for S/MIME, it will disable "combined" sign and encrypt.

Werner said to put this on hold till he fixes the bkuptocard command to work in this case, too. It was originally designed for adding the subkey to the original secret key, there was no need to update the pubkey then. But in the usecase here we have a different secret key, as the original one was lost.

Note: I decided to add "detached" or "embedded" before "signature(s)" to give a hint where the signature(s) come from.

it will be Sune_Vuorela_FPR_public.asc hopefully soon. and hopefully ascii armored.
I don't have the key-id handy, only the full fingerprint, and I'm not sure we should be playing scrabble with the keyId in Okular code. I'll see if I at some point can get the keyid thru.

Issue of the FAILURE split into T8340: GpgSM: Decryption with multiple recipients emits a failure, if the first pinenty is cancelled

In T8334#220115, @pl13 wrote:

The error comes from this log error message. Cancelling the pin entry leads to Operation cancelled. gpgsm exits with an error if an error was printed with the log_error function.

I (try to) restore the original content of this file, as I mixed up backup formats .gpgsm with sk_keyID.gpg.
As the .gpgsm format is put on hold currently, I'll set this to wishlist for the moment.

Fixed and backported for VSD 3.4.

It is more a regression (compared to older behavior that's still used for detached S/MIME signatures) that the full paths were shown. Therefore, I'll backport this for VSD 3.4 (as originally planned).

Fixed and backported for VSD 3.4.

This fix should be backported for VSD 3.4.

• The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

In de-vs mode we have to check the certificate chain which is done after we successfully decrypted the session key. Checking the certificate chain includes a CRL check (which is done by the dirmngr).

Seems I am behind the times ;-)

Are those other issues something to look into?

• FAILURE at the end of the second gpgsm cli command output (pinentry dialog for the first recipient is cancelled, second one is entered correctly)

The error comes from this log error message. Cancelling the pin entry leads to Operation cancelled. gpgsm exits with an error if an error was printed with the log_error function.

• The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

This is related to T8333: Kleopatra: S/MIME decryption fails for certs with crl check problems.
In de-vs mode we have to check the certificate chain which is done after we successfully decrypt the session key. Checking the certificate chain includes a CRL check (which is done by the dirmngr).
With 4a8f177f390b270df9a86ea47d8eced85420d7d4, this should only happen if we are actually in de-vs mode.

In T8293#220072, @ebo wrote:

Well, Kleopatra keeps the whitespaces in names. If you handle them differently it will again deviate from what Kleo does.

The "missing path" on verification of test.txt is caused by a bug in the code: T8337: Kleopatra: Verifying detached OpenPGP signatures uses different code paths.