genkey for Ed25519 works now with libksba in master.

For public key, it's done.

thanks!

Done; will go into 2.2.21 (T4897).

Thanks.

The problem was the comment field which was not expected in an rsa key. However ist makes sense to allow additional fields and thus I pushed a change to Libksba.

This bug is linked to restoring window size in case of multi-monitor multi-DPI setup.
There is QT bug report: https://bugreports.qt.io/browse/QTBUG-77385

Thanks for following up!

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

Nine months have passed since the patches for this problem have been available.

I recall that I talked with Stephan about it but things got lost.

NIST P-256 key generation looks good.

Of course it is important, that's why it it printed by default.

This is an important information to know because it can help to avoid bug reports.

OK, i've asked on gnupg-devel.

Please use the mailing list for help on generating keys. I would also suggest to use GnuPG master for such experiments.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

If you run into build problems on OpenBSD for gpg-wks-server, see T4886 for a required minor fix.

No info received; either really malware downloaded from a fraudster site without proper checking on bare coincidence with other updates.

@sarman: Your question is actually a support question and not a bug report. Please read the documentation, use the public help channels (so that other can also learn from the issue), or get in touch with a commercial support provider.

There are two code paths to generate key: gpgsm_genkey and gpgsm_gencertreq_tty. Latter is partially supported with card key.
Firstly, I'm going to work for T4888.

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

This should work well with libksba master and gnupg/sm master.

The commits in 2019 (for libksba and gnupg/sm) handles the problem (of key generation using card).

For operations which require private key, it is needed to unlock private key.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?

In T4883#133467, @werner wrote:

That option does the same as --disable-dirmngr which in trun has the same effect as disable-crl-checks

@werner wrote:

The return value that was mapped to invalid value was "SW_WRONG_LENGTH" so I tested using the codepath for the SW_EXACT_LENGTH sw return value, too and it worked for readcert.