The export/backup of the secret part of S/MIME certificates has been fixed with T6189: Secret key backup of S/MIME certificate creates bad result. An exported certificate should now be imported without problems.

Does dirmngr maybe interpret the redirect reply /.well-known/openpgpkey/hu/enzdc18iy17uy9qb3pwm4ay9a1ga6mb3/ as URI? That would explain the error because without protocol the redirect reply is indeed an invalid URI.

All commands should work as before (or more robust if a key listing happens while the command is running). Setting to resolved because there isn't anything that can or should be tested specifically.

Now "BER error" is reported, if the user tries to import a .p8 certificate. (The certificate exported by Kleopatra wasn't stored as PKCS#12, but presumably as PKCS#8 which gpgsm cannot import. See T6189: Secret key backup of S/MIME certificate creates bad result.)

This was broken by a regression in the P12 parsing code.

In T6014#163083, @aheinecke wrote:

I think it is problematic that the WKD errors are shown to the user at all. Doing some random searches gives an error each time something can't be accessed.

Thanks for your help analysing this problem.

Wouldn't it make more sense to pass the decrypted text back (wrapped into a minimal rfc2822 message) to a MUA if it turns out to be another MIME tree with attachments and what not? After all, parsing and showing MIME trees is what MUAs are really good at and many MUAs should be able to open an .eml file.

If any notepad operation is canceled, then there shouldn't be any error messages or result widgets (the frame with the Close button in the screen shots) anymore.

Fixed.

To debug this you can enable logging of the dirmngr (which does actually talk to the keyservers). To do so open GnuPG System/Network in Kleopatra's configuration dialog and set the debugging level to 4 - All and enter a filename for the log file.

In T6014#163001, @ebeiersdorfer wrote:

OK, so this warning should just be ignored then?

I have implemented this a bit differently in particular with usability (e.g. discoverability of the import possibility) and accessibility in mind:

• Add a separate Import button instead of re-using the Sign/Encrypt button.

For one, this allows the user to encrypt a public key block. Moreover,
buttons that magically change their meaning are bad for accessibility.

• Update the three crypto operation buttons in one place.
• Disable the Verify/Decrypt button if the notepad is empty.

In T6085#162918, @ebo wrote:

well, when creating openPGP keys with kleopatra I did not see any hints. I do not think that the issue would be vaild for password based encryption. There the common usecase is autogeneration, anyway

In T6085#162921, @aheinecke wrote:

@ikloecker yes as mentioned in my response the current hints are only for symmetric.

After some discussion with Andre we decided:

1. We keep both buttons always enabled. Reasoning: We do not want to disallow a valid operation just because our heuristic says that attempting a decryption makes no sense.
2. Instead of the Encrypt button we switch the Decrypt button to Import if we detect a key block. This way the users can encrypt key blocks (which does make sense; in particular, for protecting exported secret keys), but attempting to decrypt a key block will always fail.

The long hint is "hidden" in the tooltip of the short hint.

And the issue for which @ebo opened this ticket is in my opinion that you have to fail first before you see the hint.

Should be fixed.

This is most likely a regression of switching to the gpgme-based secret key export.

The error is generated in parse_import in gpgme/src/import.c:

if (errno || args == tail || *tail != ' ')
  {
    /* The crypto backend does not behave.  */
    free (import);
    return trace_gpg_error (GPG_ERR_INV_ENGINE);
  }

Does the problem even occur if the secret key stubs have already been created?

I think this is mostly an issue during the setup of smart cards because Kleopatra lacks the functionality to delete the locally stored secret key without deleting the public key. Therefore, currently, it is necessary to delete secret and public key and then to re-import the public key.

inflateGetHeader does not seem to be called by anything from KDE. The only hits are from a copy of zlib included in marble.
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=inflateGetHeader

Please give a step-by-step description how to reproduce this.

I'm asked three times for the passphrase, but otherwise I can confirm this.

Possible root cause: The S/MIME details window seems to lack a parent.

I have introduced this hint exactly because it's impossible to describe the rules automatically.

These hints are taken from the help.txt file.

gpg-agent passes to pinentry a short and a long hint for the passphrase constraints (see constraints-hint-* in pinentry.texi). If these hints are set, then pinentry shows them even before the user has started to enter a passphrase. The error message can then simply be "Read the hint, stupid!". Just kidding, of course.

We could use single letters or icons (with proper tool tip and accessible name). I'm not sure mentioning the cert usage is that useful.

I found the following issues while testing with NVDA:

1. In the Certificate Details dialog NVDA does not read the labels associated to the key properties when a property gets focus, e.g. it reads the expiration date, but it does not read the label "Valid until".
2. In the Certify dialog the "Advanced" expander lacks a focus indicator.
3. In the Certify dialog the explicitly shown tool tips are not read.
4. In the Certify dialog the explicitly shown tool tips are immediately closed if the mouse pointer is over them or if the mouse is moved a short distance.
5. When a dialog is opened, then a label that has initial input focus lacks a focus indicator.

Fixed

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

At least, pinentry-qt offers this functionality since 1.2.0 (see T5517: Improvements for symmetric encryption).

Isn't this (mostly?) done? See T5517: Improvements for symmetric encryption.

pinentry 1.2.1 has been released today

I'll flag it for re-testing with the next version.

The (): is the result of Formatting::formatForComboBox(d->key()) which has just been changed to Formatting::formatForComboBox(target) to fix T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. I think this issue here is just another symptom of the same bug as in T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. You were just quick enough to avoid the assert.

Looks like this option has been merged 16 years ago from gpg 1.4.3. My guess is that it was never used in gpg 2.x.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Should be fixed.

This (old) task only concerns OpenPGP smart cards resp. the OpenPGP card app, right? Because for PIV ECC has always been offered since PIV is supported. And for other card apps we do not even support generating keys AFAIK.

scdaemon should return this information together with other information about the smart card or the key slot.