If you encounter real world certificates with these parameters we can bump up the priority.

Why do we need a word list if we are a password storage tool?

In case of build problems related to a failed test you may want to apply rEb6df311368133df90c3bf338fbf5c90bd8d950f8.

If you want to write a new thing please also consider the rendering hints gpg-agent can send to the pinentry. This is enabled if the Pineentry sends back a FEATURES sstatus tring with the keyword "tabbing".

FWIW, the original idea with Pinentry was to have a stripped down Widget which allows to securely enter the password. For that we even replaced the Gtk text widget to have better control over the code path from keyboard to screen. After a few years more more more stuff was requested and meanwhile the QT version of the Pinentry is probably larger than the gpg-agent process.

See this comment which is related to T4538:

Note: The is a bug in the gnupg-w32-2.5.3 tarballs. After untaring cd to the directory as usual but then do:

rm PLAY/src/zlib/*.[oa] PLAY/src/bzip2/*.[oa]

before you run

make -f build-aux/speedo.mk this-native

2.2 is end-of-life.
There was one actual typo fix which could be used for master, though. Thanks.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.

There is a regression due to the regression fix in rGb30c15bf7c5336c4abb1f9dcd974cd77ba6c61a7 (from Dec 24 2015) or some related commits:

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Check out the GTK version which scans /proc for the process to find the command line. Very handy for ssh sessions.

Note that that Beta uses a 64 bit Kleopatra but the GnuPG engine was accidentally build for 32 bit. This will be fixed with the next Beta. That might increase the confusion a bit.

All applied.

it would be best to add an API to gpgrt to iterate over registry entries.

But keep https://www.cs.auckland.ac.nz/~pgut001/pubs/heffalump_crypto.pdf in mind ;-)

That is what I expected. Meanwhile I re-read the code and history and can tell that the comment is not correct. I wrote it with PQC security level in mind which requires AES256 for the session key as well. However, during the migration phase and as long as --require-pqc-encryption is not enable we should allow an AES-128 session key. This is for the rare case that encryption is also done for non pqc keys which don't have the AES-256 capability set.