Page MenuHome GnuPG

Kleopatra: Add support for adding an ADSK
Testing, NormalPublic

Description

So we now have deployed the ADSK feature in 3.2 https://gnupg.org/blog/20230321-adsk.html so we can assume that for 3.3 a lot of clients will have support for that.

In Kleopatra the UI needs to be different from just adding a General subkey though, you basically need a certificate line edit to select a public certificate which should be used as ADSK and clearly indicate "Warning: Every client with support for this will additionally encrypt to this certificate. This means that every message you will receive can also be decrypted by "$Key".

Event Timeline

TobiasFella moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jan 3 2024, 2:29 PM
ikloecker set External Link to https://invent.kde.org/pim/kleopatra/-/merge_requests/88.May 8 2024, 10:12 AM

Let us drop the option to select the ADSK and instead take them from the gpg.conf configured ADSK for new keys. Thus a simple dialog with a confirmation will be sufficient. We add some magic to gpgme to allow this with the adsk API. This solves the use-case to add ADSK to alread-existsing keys in the same way as they are added to new keys.

Makes sense. Then default-new-key-adsk needs to be exported by gpgconf, so that gpgme/Kleopatra can use/show it.

Noticed when looking at the MR that there seems to be no error handling for the case that no ADSK is configured (or something is wrong with the configuration). At least I did not see any strings informing the user about an error.

Of course it would be much better to not display the "Add ADSK" action if there is no ADSK configured.
But Ingo said that Kleopatra does not know this, as gpgconf --list-options gpg does not provide this info.

Would it be possible to add this?
In that case we would only need to cover errors if the ADSK was not configured correctly (I assume gpg would return an appropriate error for this) or the configured certificate is not available. And we would not have to explain the action in more depth.

TobiasFella changed the task status from Open to Testing.Jun 24 2024, 9:50 AM
ikloecker changed the task status from Testing to Open.Jul 1 2024, 7:53 PM

The option "default-new-key-adsk" of gpg can now be read with Kleo::getCryptoConfigEntry, so that we can check if an ADSK is actually configured to decide whether it makes sense to offer the "Add ADSK" action.

@TobiasFella Please add such a check.

The version check can now be extended to 2.2.45 <= gpg < 2.3.0.

Backported for VSD 3.3