This works, basically.

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.

works now, Gpg4win-4.1.1-beta295

works

works with Gpg4win-4.1.1-beta295

The workaround works.

I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html

I imported only a secret key file generated by "Backup secret key"

Fixed for libgcrypt, updating copyright notices and license files.

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.

works. Including "Verschlüsseln".

See T6474 for the remaining issue.

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

@ikloecker Thanks for your comment. I put a comment in the commit.

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.