The simplification works as described except in the following case for importing a private key:

File dialog and notepad now share the last used signature and encryption to self key. Works.

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).

That is basically the key signing party scheme we developed at the keyserver convention in Utrecht in 2000. Sometimes also known as Sassaman or over-the-lunch protocol. Gnupg used to come with a tool named ring-a-party which did the paperwork. However, experience has shown that it is too hard to explain and get right - even to key signing party geeks.

So, here are fixes. I'll apply soonish.

Sorry, the comment above is my misunderstanding.

For importing key/subkey case, it doesn't matter if the smartcard is connected or not. The data in the file will be overwritten by import.

The checksum part for this was mentioned only in relation to T6470

I understand the issue that you don't see an important message of the error.
Possibly, for this particular case, it would be changed to tty_printf instead.

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 default time period for warning about pubkey expiration is 14 days in the old Kontact (IIRC).

Why? The idea is that someone might trick you by having printed out "Andre Heinecke <aheinecke@gnupg.com> 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1" Then adding the ID "Ingo ...." and sneakily adding that to the .krgp.

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.

I recently had a workshop with a customer that shared the same secret key inside her organization of about >1000 users and even handed it out to external users to avoid having any hassle with public key management. They did not have the highest security requirements and were mostly concerned about transport encryption.

This works if the smartcard with the same private key is not connected, which it usually shouldn't be (outside of testing situations) so that's ok for me.
But I think we should inform the user what is done or isn't.
Currently we get in both cases:

gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
gpg:              gelesene geheime Schlüssel: 1
gpg:            geheime Schlüssel importiert: 1

Which is not very clear in any case but in case the smart card is connected it is in fact wrong, there is no secret key imported, the keystub remains.

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.

Ok, so this is not an issue for a standard user. Still I think "wrong PIN" should be given on the command line, too, and not only in the debugfile output.

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.

works, at least for Yubikeys and Zeitcontrol cards

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.

What it does (in g10/card-util.c:card_store_subkey) is:

if (rc)
  log_error (_("KEYTOCARD failed: %s\n"), gpg_strerror (rc));

Here's fix for mode specific setkey clearing error code:

The commit hashes are different:

• Here: 81a281183ff949fc88ef187118bbf3e89f4466ac (81a281183ff9)
• At GH: 35b9de6461762ff4849ebd7aa277f453b7f42be9 (35b9de6)

True, also because this works well when resolving a merge-conflict locally.