re 1: Only if the option --auto-key-upload is used/configured.
re 2: Do not configure --auto-key-upload but give it on the command line.
re 3: Do not use --auto-key-upload - maybe I should add a --no-auto-key-upload option.

Hi
I have some questions about the "auto-key-upload: If an LDAP keyserver is configured (in dirmngr), upload a newly created key directly to that server" feature:

1. If an LDAP keyserver is configured, will every newly created key be uploaded? Is this upload behavior enabled by default?
2. Even with an LDAP keyserver configured, what if we don’t want to upload by default? If we prefer manual approval or want to upload only a specific subkey, how should we handle that?
3. What about keys created for testing, temporary use, or personal privacy-sensitive purposes that we don’t want others to discover?

People who use GPG tend to care deeply about privacy and don’t want to upload or expose unnecessary information.

The culprit seems to be commit rO6cb4ccf4d8db03e9922984d9c5f5bf7f8806954d but a brief inspection does not show any problematic code. Thus this might be due to an Outlook peculiarity.

Mostly looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10
(tested with 10 restarts)

looks correct

Mostly looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion) @ win10

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion)

Looks good to me on GnuPG-VS-Desktop-3.3.90.8-Beta-Standard.msi (3.3.3 betaversion)

works in vsd3.3.3, tested with VS-Desktop-3.3.90.8-Beta

The gold rule of tab order is that tab order follows the usual reading direction, i.e. line by line from left to right. If you press Enter after entering the password in the first input field then the focus should jump to the second input field.

Looks good to me on gpg4win-5.0.0-beta357 @ win10:

The fix should be available in gpg4win-5.0.0-beta350.

I could not reproduce this issue with Gpg4win 4.4.1 and did not see it with Gpg4win-5.0.0-beta345, either.

I could not reproduce this issue with Gpg4win 4.4.1 (which should have it).

In T7639#202620, @timegrid wrote:

If this should also work in gpg4win-5.0.0-beta336 @ win10 (beta compliance mode), it does not:

If this should also work in gpg4win-5.0.0-beta336 @ win10 (beta compliance mode), it does not:

Can be tested with next VSD 3.3.x build.

I have added the changes/patches to the vsd-3.3-branch of gpg4win

The relevant changes have been merged to the gpg4win branches of kleopatra and libkleo. We can start creating a test build

Parts of the changes made for T7183: Kleopatra: Reduce certificates offered in Sign/Enyrypt dialog have been reverted. The drop downs for selecting the signing key and the "encrypt to self" key now offer the primary user IDs of usable keys again (instead of all user IDs of usable keys) and there's no button to open a certificate selection dialog anymore.

This one made me curious because updating the should be UI solved, and it is incredibly dangerous to mess with that. It is super easy to get random crashes when you invalidate the UI too much. It took me ages to get that "stable enough". But also technically an appointment request is a mail. And thanks to dan (afair), KMail can sign and encrypt invitations. And at least for signed invitations they are displayed as appointment so I looked into this a bit out of curiousity.

Backported for VSD 3.3.x

yes please!

Fixed:

That error code is actually not an error code but it is the ERROR state from the Kleo SFM. We have seen that yesterday already.

this exact case is fixed in VS-Desktop-3.3.90.12-Beta
Adding further UIDs and making more certifications still works, too.

Very likely this bug exists since 2017 when support for promotion of local certifications to exportable certifications was added.

Fixed in gpgmepp for gpd5x. I think for VSD 3.3 we'll add a patch to gpg4win.

yeah, I did not have exactly the same setting for the tests in the different versions… so no regression

After further investigation it looks like this bug exists since quite some time.

The state machine in GpgSignKeyEditInteractor expects to see GET_BOOL sign_uid.okay and it should have answered with Y.

The dialog between gpg and Kleopatra looks like this:

[GNUPG:] KEY_CONSIDERED FADC4675146CFAF3D86F137E1D3C5E6E3DB3C71D 0<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
sign
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_BOOL keyedit.sign_all.okay<LF>
N
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
uid D2C00A207DC184562E41517CBC5EF7175E8535E8
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
uid 648AC172C3EC45F85AA2E68E46D3FEFABD1F5BD7
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_LINE keyedit.prompt<LF>
sign
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] KEY_CONSIDERED FFDFEE2F0C8F278023284D90B0FBC8D8324859B9 0<LF>
[GNUPG:] GET_BOOL sign_uid.local_promote_okay<LF>
Y
<LF>
[GNUPG:] GOT_IT<LF>
[GNUPG:] GET_BOOL sign_uid.okay<LF>

and then nothing else.

with VSD-Beta-3.3.90.10:

this is not yet in master and not included in the current testbulid

My above comment is true for the main case described in the ticket, cancelling decryption followed by "permanently decrypt".

I see no improvement in VSD-Beta-3.3.90.6, the issue persists.
Btw: Is this maybe related to T7596: GpgOL: Draft is not decrypted after cancelling decryption once?

with Version VS-Desktop-3.3.90.6-Beta: