Setting close_button when the user rejected the pin entry (by pressing the close button, the Cancel button or Esc) causes fully canceled. Unfortunately, Kleopatra (and in fact GpgME::Error) has no idea that fully canceled should be treated as canceled and not as error. Therefore, Kleopatra shows an ugly error message:

An error occurred while trying to change the passphrase for [...]:
Operation fully cancelled

The output folder is now checked with enabled NTFS permissions check for writability. Hopefully, this fixes the problem on Windows.

Kleopatra explicitly checks if the output folder is writable using QFileInfo::isWritable. But: QFileInfo::isWritable mentions that NTFS permissions are not checked unless this is enabled explicitly (because it's an expensive operation). I'll try to enable it locally for the check.

On Windows, we had to revert to the old approach which doesn't show progress because KIO::move doesn't work on Windows when crossing partition boundaries. We want to fix this in KIO for a future release. Windows users will have to live without progress for now.

Fixed as suggested by Andre. Additionally, I have added support for hidden files in the old code (which are probably not really a thing on Windows). The downside is that there is no progress on Windows (as before the switch to using KIO::move).

The warning is now removed immediately, when the input field becomes empty.

In T6473#170571, @ebo wrote:

In T6473#170380, @ebo wrote:

And when I set the validity to never expire (works) and afterwards set it to a date again, the date is now only set for the main key

Update: This is as designed, see https://dev.gnupg.org/T6473#170299 point one.

This bothers me a bit, as I find it confusing. Werner suggested for subkeys without explicit expiry date we could show in Kleopatra the expiry date of the main key in grey to make it visually obvious that a subkey will expire implicitly when the main key expires.

What do you think?

In T6330#170382, @ebo wrote:

[...] The only drawback is: for the message to be displayed in the "for others" part of the encryption dialog you have to click in the next line before it is displayed.
If you click on sign/encrypt directly, you won't see the warning. At least if you select the recipient by starting to type and the selecting from the dropdown.

@aheinecke As I wrote "the thresholds should be shared by all applications". Therefore (and because the code is in libkleo), using kleopatrarc wasn't an option. Or is the question why I didn't use libkleopatrarc? One advantage of using a separate file is that watching for relevant changes by other applications is much easier resp. that one doesn't get change notifications for unrelated settings.

Yes, kleo-expirycheckerrc is optional. I'm not sure where the config files live on Windows. It's used by libkleo, so it could also be %APPDATA%/libkleo. The setting in the appearance tab is stored in kleopatrarc. (I thought it makes sense to have the warning configured per application, but the thresholds should be shared by all applications.)

Instead of using gpg --quick-set-expire with the * wildcard for the subkeys to update, the subkeys to update are now listed explicitly. This way the last three options from my comment could be implemented, i.e.

• Subkeys without explicit expiration are not updated. Note: This doesn't work for already expired subkeys because gpgme has no way to know whether an expired subkey has an explicit expiration set because gpg --list-colon always prints an expiration date for subkeys of expired keys.
• Not yet expired subkeys with explicit expiration are updated.
• Expired subkeys which expired at the same time (+/- 10 seconds) as the primary key are updated.
• All other expired subkeys are not updated.

Adding @werner @aheinecke to get their feedback especially on the options at the end of the previous comment.

@Angel thanks for the valuable feedback

fixed

This is basically working as intended by gpg --quick-set-expire. With a first call of gpg --quick-set-expire the validity of the primary key is extended. With a second call of gpg --quick-set-expire with third option * gpg is asked to update the expiration time "of all non-revoked and not yet expired subkeys".

Setting priority to high because this should be fixed before the next release.

I have checked that we now switch back to openpgp (if necessary) after every use of ReaderStatus::startSimpleTransaction and ReaderStatus::startTransaction. The only uses of those functions outside of subclasses of CardCommand are by PGPCardWidget for which switching back to openpgp isn't needed.

Note that this change has the inconvenient consequence for the users that they will have to (re-)enter the PIV Authentication Key for each operation that requires authentication, e.g. for each write operation (generate key, write key, write certificate), because switching to openpgp seems to reset the PIV authentication.

Did you by chance import the public key file and the secret key file for the same certificate?

Note to self: This might happen because the key is/was expired.

The readability would be much improved by adding named constants for the magic numbers 2 and 4.

As discussed, this should be done before the next release.

The default validity of certifications is now configurable via the setting CertificationValidityInDays in the group [Certification]. It cannot be configured in the UI.

Note that this may not work for Python 2.7, but since those are just examples that doesn't matter that much.

Additionally, in the case of a keysigning party you will only want to import the keys of those persons who did actually show up. Which means the group of imported keys will typically be smaller than the printed group of keys, hence any checksum over both sets of keys will never match regardless of some clever sorting which may work for identical sets of keys.

I understand all of this. I'm just pointing out that it's impossible to check the checksum of the file when you are certifying the imported group. The checksum needs to be checked when the file is imported because we need the file to calculate the checksum. Moreover, the checksum should be verified before the keys are actually imported because it may prove impossible to get rid of the imported keys after the import (because some keys could already have been in your keyring, so that you cannot simply delete all keys).

In current Kontact and now also in Kleopatra, by default, it's 30 days for own certificates and 14 days for all other certificates (including certificates in issuer chains), but Kleopatra currently doesn't notify the user about expiring issuer certificates.

I don't see how to calculate a checksum reliably if all you have is an arbitrarily sorted list of keys.

The Dialog to certify all keys should show a checksum over all the keys signed as I have a related subtask in mind for exchanging printed .kgrp files.

Good timing. We have just added the necessary bits to the shared libkleopatra. They just need to be used in GpgOL. See T6330: Kleopatra: Additional Expiry handling.

Ready for testing.

In T6466#169934, @werner wrote:

Funny enough that Python seems not to allow to set the permission with open. Low priority because a proper umask must anyway be used on a multi-user system.

A few remarks:

• For now the users are just informed about the upcoming expiration of certificates used in the Sign/Encrypt dialog. There is no button to act or get further information what to do about it.
• Expiration of issuer certificates are ignored. If a leaf certificate gets invalid as soon as any certificate in the issuer chain expires, then it may make more sense to treat this as expiration of the leaf certificate since that's effectively what happens. On the other hand, if the expiration of certificates in the issuer chain have no effect on the validity of the leaf certificate (because at the time the leaf certificate was certified the chain was valid), then, in my opinion, it makes little sense to bother the users with the expiration of chain certificates.
• I took over the default values that are also used by KMail and that seem to be the recommended default by SPHINX (according to the comments for the settings in KMail).
• I decided to save/load the thresholds from a shared configuration file (kleo-expirycheckerrc), but to keep the setting whether to show expiry notifications as per-application setting.