This can be bypassed by entering the date manually, was reported by a customer and I have just confirmed this.

Looks like somebody is writing to the shared config after it has been destroyed already. Probably some global object that is destroyed by the runtime on shutdown.

Tested

The issues mentioned in the previous comment have been fixed.

I had a look at the file system watcher we use to react on changes in the GnuPG home directory. It doesn't watch the private keys living in private-keys-v1.d. Moreover, it does not handle the removal of files properly.

Anyway, since you have replaced the only usage of is*Immutable in kleopatra, I'll close this task.

Fixed. Until the lookup is completed, a question mark icon should be shown and no error should be displayed.

In this case it works, because the error messages are not translatable.

In T5939#157259, @werner wrote:

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

I have added the check for a possibly wrong symmetric password to QGpgMEDecryptVerifyJob because it relies on logging messages emitted by gpg which are not part of gpg's status API.

The error

gpg: decryption failed: Bad session key

is only logged if the sanity check "algo given in decrypted session key is a valid OpenPGP algo" passes even though a wrong password was given (which happens with a chance of 11:256). If the sanity check detects a bad algo then gpg logs

gpg: decryption of the symmetrically encrypted session key failed: Checksum error

If AEAD is used, then other logging will happen.

For the record the Task for the fingerprint copy was T5776

I tend to disagree. The fingerprint is a very long and cryptic looking thing. Most users of Kleopatra will never share their fingerprint as they tend to work on a TOFU model, just accepting a given key and using it. For another bunch of users the long keyid, which we show, is more then enough security. And for the VS-NfD case with very high security where users compare a full fingerprint it is accessibile enough.

Ahh, this is about cross-compiling. I keep forgetting this.

We use the tooling from debian buster. We do not compile any host tooling as part of the build, except for QtBase tools.

I'm wondering if this happens when users have made some other application window active. In this case, I'm pretty sure there is no way on Windows to bring the result dialog to the front. An alternative might be to use a notification to inform the user that the operation is completed, either always or only if we notice that the result dialog isn't active.

I'll close this. Feel free to reopen if you think this would still be useful.

In T5716#152555, @aheinecke wrote:

Ingo: Exactly we have the problem that we don't compile build tools before building for the target. So we take the build tooling like kconfig_compiler from the system we compile on. This means that we compile with the tooling from debian buster. Except for Qt which handles stuff like that directly and builds for example moc and the other tools correcly for the build system first.

For the record, I am for the deletion as long as it is guarded by a safety check.

Done. Note that different from the comments in your example a non-negative ValidityPeriodInDaysMax value implies that an expiration date is required. This way it's possible to require a validity period of at least 10 days, but still allow unlimited validity.

Done. This also fixes the state of the encryption check box in case the OpenPGP key type is forced.

In Kleopatra's KeyToCardCommand there is this comment

/* TODO DELETE_KEY is too strong, because it also deletes the stub
 * of the secret key. I could not find out how GnuPG does this. Question
 * to GnuPG Developers is pending an answer

before a commented out code snippet that asks the user whether the key should be deleted locally and, if the user confirms, asks the agent to do DELETE_KEY --force <keygrip of subkey>.

Done. I have also tried to make this dialog as accessible as possible as prototype for other form-like dialogs. The error reporting could still be improved by specifying what exactly is wrong instead of simply saying what could be wrong, but QValidator is too limited for this.

We should give this higher priority as users need to change their e-mail through kleopatra. A customer also wishes this.

"Revoke certificate" is now available in the "Certificates" menu and the context menu in the certificate list. Don't confuse it with the "Revoke certification" entry. ;-) Maybe we should reword "Revoke certification" even if for me it says exactly what it does.

Ingo, it would be great if you could work on that. For me the most intresting use case is to fully revoke a key because it has been superseeded.

I'm also seeing this, but that's probably due to me using "focus follows mouse" and the pinentry being a different application. When the pinentry goes away the window manager gives focus to the window below the mouse which very often isn't Kleopatra when I have been testing keyboard navigation.

I wonder if we even should change gpgme to do a key refresh when you call it in VALIDATE mode and online? Semantically this makes sense to me as this is where CRL checks for S/MIME are done. But from a conserviative standpoint this could be considered an API change if the API then does something differently and that even does a network connection. So while I consider it I don't think this is a very good idea.

This occurs on Windows. But if a raise is really missing, it might also occur with other window managers.

On which OS resp. with which window manager does this problem occur?

There is a new key filter "Not certified certificates" that is selected if the button is pressed.

Yes, makes more sense to me, too. Maybe another filter "bad" certificates, so that you can bulk delete them for example to clean up your keyring?

@aheinecke What do you think?

From the parent task "I think having the [...] keyselection when encrypting improved is the best way to help current users of the software who might already have received help from a collegue to import and have a list of certified certificates available."

Ready for testing

Thanks, I always did it differently and never saw that because I changed the read only configs.

KConfig simply reads all sections with the same group name into the same KConfigGroup. I strongly suggest not to use`[$i] on groups. KConfig` will anyway add [$i] to all config entries (and remove it from the group) when the configuration file is saved the next time.

I tend to agree

Removing the list seems reasonable to me, we can tell users in support that they should go to settings- > Smartcard to select the reader used.