I went through my test files and found that --enarmor on zero length input file did no longer work. I made separate patch to fix that issue, which then also needs another approach for handling compress issue noticed earlier:

Ack from me for new 0005 and 0006.

Does this look ok to push to master? @werner @gniibe

New versions of patches 0005 and 0006 - fixes EOF handling issues noticed with compression/decompression:

Great. No problem for me.

I used "1<<30" by example of existing code in g10/free-packet.c, which is another place where iobuf_read is reading to NULL.

Patches look good for me.
Please go ahead.

Does the patches look ok to push to master? @werner @gniibe

Feel free to ask me by PM if you run into problems (wk at gnupg.org). Two of my colleagues are Vim users and thus have an interest in a well working plugin :-). Thanks.

I have tested it. When I try it with public keyserver it has of course problematic results when vandalized keys like werners are hit but its great that even if I abort at that point I nicely see the results of the other imports.

Optional automatic retrieval after import of new OpenPGP keys is now also possible.

Yes, it would be convenient to use the same $GNUPGHOME in Git Bash (using /usr/bin/gpg) as in PowerShell / Cmd (using gpg.exe in %PATH%)

Manual retrieval of missing certification keys is now possible from the Certifications dialog.

As this hinders the trusted-introducer setup in Keyserver centric deployments we should treat this with high priority.

vitusb: We had this discussion on cryptography@ years ago. No need to start it again - or well, try it over there. This is a bug tracker and not a discussion forum.

These curves are not the default in the compliance mode "gnupg" only if you explicitly switch to the BSI defined "VS-NfD" mode they become default.

In T5783#153879, @werner wrote:

Sending a private key with just the local protection is not a good idea.

In T5784#153872, @werner wrote:

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

Sending a private key with just the local protection is not a good idea. It is better to export the key and then send it in an encrypted mail - for example in symmetric mode with a strong password.

Please no holy wars on the type of curves. NIST as its opinon, Europe has its opinion, DJB has of course a different opinion. Please use the the cryptography ML for such political/technical discussions.

I found this post when I was searching everywhere for a solution, and I was delighted. I've recently been trying to upload GpgFrontned in the Apple Store vs Microsoft and I'm having some trouble.

The odds for this case are infinitesimal so this should not have high priority. I consider this only a code-is-as-specified thing.

We can even remove the hexfingerrprint call. Will go into 2.3.4. Thanks.

So, this is the patch. Note that this is for master.

diff --git a/g10/keygen.c b/g10/keygen.c
index 7f15027a2..a452ab6d6 100644
--- a/g10/keygen.c
+++ b/g10/keygen.c
@@ -5619,7 +5619,7 @@ do_generate_keypair (ctrl_t ctrl, struct para_data_s *para,
           pk = find_kbnode (pub_root, PKT_PUBLIC_KEY)->pkt->pkt.public_key;

The use of register_trusted_key in do_generate_keypair was a dirty hack utilizing a bug in --trusted-key ; it would be better to set the key as ultimately trusted.

I think that the change for T5685 introduced the issue.

Okay, sorry. In the first two cases (encryption), GnuPG 2.2.33 generates

[GNUPG:] INV_RECP 10 F3C987C36C5C6343C9A5D5A1A3F494F6028E4866
[GNUPG:] FAILURE encrypt 53
gpg: [stdin]: encryption failed: Unusable public key

and exits with error code 2, whereas 2.2.32 doesn't display these messages and exits with return code 0.

Please be so kind and describe the regressions you see. 3 log files from your software are not very helpful.

The first is a warning and the other error codes are exactly what we want.

Not a bug but a limitation of 2.2's option listing: In contrast to 2.3 we can't *show* the used options via gpgconf correcly if there is a conflict between global and local options. However, the actually *used* values are different and correct according to the config. In particular a global forced option overrides any local or command line option.

No, too much release work. Better just one AppImage. Or well one VSD (based on 2.2) and one regular (based on 2.3)

Not sure if we want a separate AppImage for gpg & Co. Setting priority to "Needs Triage".

@werner That is not helpful. I tried 4 or 5 different readers. And the Reiner SCT cyberjack is the one that works best out of all of them on both Windows and Linux.

Do not user Reiner SCT those readers are all buggy and work only on Windows - if at all. Stay away from them and get a real reader and not the incompatible broken stuff from that company. I spent way too much time trying to get those readers working. That time is better invested in support for hardware which is standard compatible or are helpful to get stuff running.

Some more info: OpenVPN does not care about the second reader only gnupg agent is sensitive to what is present when it is started. So a workaround that I just found is to disable the Virtual Smartcard reader first so that only the ReinerSCT smartcard reader with an OpenPGP V3.4 card is present. Make sure to open an SSH connection. Then reconnect the second reader. And reconnect to VPN. After the PIN for the OpenPGP V3.4 card is already cached and a connection to the card established I can also open more SSH connections with the second reader attached and disconnect and reconnect the VPN as I want.
Even removing the smartcard from the ReinerSCT reader and plugging it back in works and I can still authenticate with new SSH tunnels and both readers present. So it seems it is actually only important which readers are present when the agent connects for the first time.
So this is a practical woraround. Although disabling the TPM backed reader temporarily needs Admin rights and is really janky.

I am on Windows 10 21H1 and I using gnupg-w32-2.3.3_20211012 from here [1]
Together with win-gpg-agent, which extends gnupg to play nicely with Windows sockets. [2]

In T5598#151696, @aheinecke wrote:

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

I compiled the Appimage with the scripts in Gpg4win and it runs Kleopatra and works :-)

Tehre has never been an option "shared-access" in GnuPG. At least not in upstream. In general we suggest the use of the interal ccid driver, but if you want PC/SC you need to use disable-ccid-driver. This is because 2.3 does not feature an automatic fallback to PC/SC anymore. Using pcsc-shared with OpenPGP cards can lead to surprising effects. You may want to try Scute as PCKSC#11 access module.

So, I have something working… in the apparent absence of any sort of clear documentation that I could find. I had some time on my hands this afternoon, so had another look.

This has not been set high on the priorities, because keyserver access works for most with Gpg4win (and thus GnuPG) on windows. A recent exception has been occurred about a month ago with Let's encrypt expired root certificate. So currently for Gpg4win 3.1.16 you need to update to a newer GnuPG (Version 2.2.32 at time of writing), by installing the simple installer,e.g. https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.32_20211006.exe

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

I did in fact check --status-fd before, but I'm not sure whether it gives me the information I wanted.

Please use the --status-fd interface. This yields all the info you need. An exit code is not distinct enough for such purpose and you need to check the status lines in any case. For scripting gpgme-tool or gpgme-json might be useful as well because they do all the nitty-gritty parts of using gpg correctly

Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.

In my understanding, it should be possible to wait for the gpg command pipe from a different process and then terminate the connection on a timeout, kllling the process eventually. So the Enigmail side could implement something. These days I'm not sure what Enigmail uses for OpenPGP support. Thunderbird has moved on to a different implementation and Enigmail stops supporting Thunderbird 68 in two days https://www.enigmail.net/index.php/en/home/news/71-2021-08-31-end-of-support-for-thunderbird

Well, as I've said in the comment above, there doesn't seem to be any correction towarads --passphrase-fd not requiring --pinentry-mode loopback (still works withou)... and --no-default-keyring still gives the impression that it would be needed (while --no-keyring works as well).

Please don't, if you really feel like tha tis not resolved please re-open this ticket.

@werner shall I open a new ticket for the remaining stuff?

Works if one puts

rootdir = $APPDIR/usr

in the gpgconf.ctl file.