This bug exists since Kleopatra offers "Trust root certificate" (i.e. since 2010). allow-mark-trusted seems to be default since Gpg4win 2.1.0. If admins really want to prevent users from messing with the trustlist then they anyway have to use the no-user-trustlist option.

I can still reproduce case 2 with gnupg 2.4. I have to check how my local setup differs from gpg4win-Beta-64.

If we fix this bug for 2.2 we need to have a configure way to revert to the old behaviour. That needs to be a kleopatra config. Or we just don't fix this bug for current vsd but only for gpg4win and the next generation vsd.

If you use a tabbed layout you will always have the problem that some tabs have lots of whitespace and other tabs have little whitespace or even a scrollbar.

I just saw that gpg-agent has a MARKTRUSTED command which takes care of asking the question and of modifying the trustlist.txt. I guess it makes sense that Kleopatra uses this command for the "Trust root certificate" action.

In T7349#192860, @werner wrote:

Kleopatra should also not offer to add a root CA if gpg-agent's mark-trusted feature has been disabled.

Saw it in a screenshot somewhere, can't find it now. I do not have a version with that commit.

In T7329#192861, @ebo wrote:

Regarding the removal of the stretch: Now there seems to be no space at all before the description. Could we have a one-line space before it?

As this ticket is for vsd33, the nice design tweak has to go into another ticket, it will not be backported to kf5.

iirc, Kleopatra modifies the trustlist.txt on its own. The import case is handled by gpgsm which pops up boths dialogs.
Kleopatra should also not offer to add a root CA if gpg-agent's mark-trusted feature has been disabled.

When checking this out with gpg4win-Beta-64 I can reproduce case 1 (and of course 3) but not case 2:

Regarding triage: This is not widely encountered and a workaround exists

Passing ticket to werner to consider backports.

A bunch of related merge requests:

This is now merged into master

I like this patch, I created a MR based on it (with some additional simplication) https://invent.kde.org/pim/kleopatra/-/merge_requests/299

What about the simplification below. Add more authors and sort-lines as you like. There is no legal necessary to show a full list of copyright holders. Authors are not a legal term in the context of software because software is not considered a piece or art. From the GNU coding standards related to the version/about output:

The line

Please use https://bugs.kde.org to report bugs.

seems to be hard-coded into the Authors tab. I see it in all KDE applications. Maybe it can be customized.

We could simplify the copyright lines to (if we make sure that the current names are listed as authors)

Copyright 2002-2024 The Kleopatra authors
Copyright 2002, 2004, 2007-2009 Klarälvdalens Datakonsult AB
Copyright 2016-2018 Intevation GmbH
Copyright 2010-2024 g10 Code GmbH

alternatively using © instead of "Copyright". (Using both as in KMail is nonsense because © is the official abbreviation of the word "Copyright".)

and why is the link to the bug tracker in the authors tab?
We could also discuss it the KDE Bugtracker is the best place to link to for that…

When we change the About-dialog we should change some other things there, too, not only the author information.

Making pinentry issue "fully canceled" if the user clicks Cancel breaks decryption of data that is encrypted with multiple keys of the owner. The user woudn't be asked for the password of their second key if they canceled the pinentry for the password of the first key.

Note for testing:
If the environment variable GNUPG_ASSUME_COMPLIANCE is set to "de-vs" and de-vs compliance is enabled then Kleopatra should show "VS-NfD compliant (beta)" instead of "VS-NfD compliant" everywhere. ("Not VS-NfD compliant" doesn't get the (beta) suffix.)

For the second case, I think that gcry_kdf_defive should not be called with pw="". The result of FAILURE gpg-exit 33554433 comes from the log_error after failure of gcry_kdf_derive.

After recompiling, it works!

I backported the work of Andre for qt6 to master/kf5. It's in the branch work/carl/product-name-kf5

The technical background is that opening the certificate details triggers an update of the certificate and this triggers an update of the drop-down. The drop-down should still keep the currently selected certificate even if it is not offered by default.

The fix should probably be backported to gnupg 2.2 and 2.4.

The only thing that's a bit ugly is that there's no checkbox in front of "Encrypt for others" because it's mostly superfluous/redundant to the presence or absence of "other" certificates.

I'm wondering if/how we can get rid of the checkbox before "Encrypt for me". Do we even need to distinguish between "for me" and "for others"? It has always felt wrong to me that we have completely different UI for selecting my single (!) key and multiple other keys. What if I want to encrypt to two keys of me? Makes no sense to enter my second key under "Encrypt for others". What if somebody always wants to encrypt everything to two of their keys, e.g. because they use different keys on different devices? But that also applies to the file encryption dialog so maybe that's a different discussion.

In T5957#192598, @ebo wrote:

But what I don't understand is: why do we need the buttons? For other encryption actions in Kleo you can choose from all available keys, regardless of their protocol.

I confirm the fix. Using gnupg master the unit test ran 544 times without any failures or suspiciously long run time.

I played a bit with the right pane to make it less wide. Here is how it looks (still WIP)

My last comment makes things look more complicated than they are.

I'd have no objections against making it less prominent.
Instead of the "Protocol" label we could then maybe add a tooltip/info to the buttons with something like "the protocol to be used".
I know, tooltips are not popular with you ;-)

Okay, then we keep the protocol radio buttons for now, but I guess there's no reason not to make it less prominent. I would even argue that the label "Protocol:" isn't really helpful and could be removed.

In T5957#192566, @CarlSchwan wrote:

Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???

Agree

Good catch, @ikloecker !
I located the bug in GnuPG, and the fix is: rG71840b57f486: common: Fix a race condition in creating socketdir.

In the second case, gpg emits a FAILURE gpg-exit 33554433 status at the end. I think this makes gpgme consider the operation failed. I think this is a bug in gpg because gpg does not emit a FAILURE status if a wrong symmetric passphrase is entered.

In the first case, gpg emits a CANCELED_BY_USER status. This makes gpgme abort the operation. We may have to wait/watch for BEGIN_DECRYPTION / END_DECRYPTION.

Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???

When looking at Carl's first MR I had a few ideas/thoughts:

• Does the notepad really need to support S/MIME? People might want to use inline PGP with Kleopatra, but S/MIME???
• I wondering whether we should move the checkboxes to the group box titles and get rid of the group boxes and instead use KSeparators to separate the different sections, i.e.

[ ] Prove authenticity (sign)
Sign as:
------------------------------
[ ] Encrypt
Encrypt for me:
Encrypt for others:
------------------------------
[ ] Encrypt with password
Anyone ...
------------------------------
[Sign and Encrypt]

I found one reason for the intermittently failing concurrent initial keylisting. gpgsm sometimes uses the wrong socket file to (try to) connect to gpg-agent.

I don't think gpg/gpgsm tell gpgme "the keyblock used for decryption". They simply log all public keys used for encryption via STATUS_ENC_TO in the order the packets appear in the encrypted file.

There is no such concept of a primary keyblock for a subkey. Using the same subkey for several primary keys is non frequent but nevertheless seen use-case. Thus this behaviour is not ADSK specific. I would suggest to first search the keyblock used for decryption to get the name of another subkey - only if that is not found search the keyring for that subkey and thus the primary key and its user id.

In T7334#192524, @werner wrote:

For a subkey the user id of its primary should always been show.

Summarizing out-of-band discussion (please correct where i remember things wrong):

It is not of the recipient's business to know which certificate also uses a subkey. For all the user needs to know that it is a subkey which belongs to a primary key. In this regard this is not different from a shared encryption subkey as used by many sites for role addresses. For a subkey the user id of its primary should always been show.

In case of an unknown encryption subkey we could check if it's the ADSK of a known recipient and then display something like

Unknown ADSK for "Some key with ADSK <with-adsk@example.net>"

instead of

unknown recipient

Thinking about this some more, I don't think we can anything different from what's done in my patch:

Both subkeys belong to Alice from gpg's point of view

What is wrong in your opinion?

I can reproduce this with gnupg 2.2.45-beta27 (STABLE-BRANCH-2-2 69a8aefa) on openSUSE Tumbleweed.

We have this data already. The problem on kleopatra's side is that in the key cache, we add the ADSK subkey for each key that has it as an ADSK, causing a somewhat broken index and ultimately the problem seen here.