ok, discussed this with Werner and Alexander, result was:

I'd write: "This means that the data you want to decrypt was not encrypted to any of your private keys."

Things look good on Windows. A quick test using gnupg24 with backported patches did not show any hangs. More testing will follow next week.

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

Sounds very reasonable. Maybe the initial idea was to open the database directly after keyboxd start and before and connections are accepted. My usual try to optimize a mutex away - I should not do this.

I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.

I found one problem. This problem may result lock-up on Windows, I suppose.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

Tobias is working on this

Setting to Testing and WiP to reflect status of the subtasks and to get it removed from the Open Tasks list.

This was implemented by Tobias

show no text "not VS-NfD compliant" for invalid signatures

Closing this ticket as what remains open is practically a duplicate of T6869

Backported the changes in Kleopatra for VSD 3.3.

Additionally to performing the lookup also for OpenPGP cards the status messages that are emitted during the lookup are now shown in the status bar instead of with a label above the key list.

Since VSD 3.3 will likely include this change in gpgme I add the vsd33 tag.

Backported for VSD 3.3

The bug doesn't occur when the normal certification process is used because there we specifically tell gpg which user IDs to sign (excluding the revoked one).

The interactor log shows what's happening:

EditInteractor: 0 -> nextState( GET_LINE, keyedit.prompt ) -> 1
EditInteractor: action result "lsign"
EditInteractor: error now 0 (Erfolg)
EditInteractor: 1 -> nextState( GOT_IT,  ) -> 1
EditInteractor: no action executed
EditInteractor: error now 0 (Erfolg)

gpg asks what to do. Kleopatra answers "lsign".

Backported for VSD 3.3

T6512 is only for gnupg26. In gnupg24 we don't use fd-passing.

Implemented in https://invent.kde.org/pim/libkleo/-/merge_requests/132 and https://invent.kde.org/pim/kleopatra/-/merge_requests/277

Backported for VSD 3.3

Fixed.

I have created subtask T7273 for fixing the problem that sometimes not all verification results are shown.

Everything has been backported for VSD 3.3

I consider this done. I suggest to open follow-up tickets for further changes.

Backported for VSD 3.3

Backported for VSD 3.3

Backported for VSD 3.3

Implemented in https://invent.kde.org/pim/libkleo/-/merge_requests/130 and https://invent.kde.org/pim/kleopatra/-/merge_requests/275.

I have opened T7268: Kleopatra: Existing groups are not saved after editing them for the issue that was found while testing this ticket. The issue is a regression caused by changes made for T7233: Kleopatra: Certificate details dialog non-interactible when opened from group edit dialog.

Backported for VSD 3.3

Fixed.

The changes broke saving of groups after editing. See T7181#190402 and T7181#190448. -> T7268: Kleopatra: Existing groups are not saved after editing them

Copying the file to the new location works as proposed in the description, tested with update from 3.2.2 to VS-Desktop-3.2.93.33-Beta

In Debugview I see, after only opening the group configuration dialog:

Answer in non #dkgmode: Seems I don't need to evaluate the details then. However, excluding auth only keys should be a no-brainer.

In the keylist of Kleopatra or in the recipient selection of GpgOL we needed to display if the operation with these keys can be VS-NfD compliant or not. I have an encryption subkey which is compliant and aonther one that is not compliant, both are valid. Currently GnuPG will use the "last modified" of the two. And since it is not transparent to Kleopatra which subkey is used, kleopatra could not show "Encrypting to this key is compliant". Which was a requirement. Since we only tell GnuPG the fingerprint of the primary subkey as recipient, to me we would need to either directly add the subkey we want to use as recipient (with ! ) or we cannot really show it. Well maybe with a version check if GnuPG is adding this now.

Migrating kleopatragroupsrc to new location worked for update 3.2.2.0 to VS-Desktop-3.2.93.33-Beta on Windows.
kleopatragoupsrc in old location is not deleted, but a copy is written to %APPDATA%/gnupg/kleopatra

Tested with VS-Desktop-3.2.93.33-Beta, works!