VSD-Beta-481: Encrypting/signing with gpgtar on the cli and decrypting/verifying with Kleopatra works

What is the status (or maybe better scope) of this ticket? Why was it set to the milestone 2.4.5?
I do not see any improvement in Kleopatra from Gpg4win 4.4 (with gpg 2.4.7) regarding the behavior when trying to unblock a card.

Reported gnupg channel on IRC.
An ascii armored file in question was: https://github.com/syncthing/syncthing/releases/download/v1.29.2/sha256sum.txt.asc

Fixed in: rGb1857a2836c9: gpg: Fix handling with no CRC armor.

When CHECKCRC == 0 (no CRC), ->any_data was not set, resulted

	no valid OpenPGP data found.

wrongly.

works in VS-Desktop-3.2.94.481-Beta

works with VS-Desktop-3.2.94.481-Beta

Fixed in: rE0f4fe2edf5e5: spawn: Care about closefrom/close call is interrupted.

@werner I read the code of gpgme/src/posix-io.c. I understand the two points:

• For the correctness sake, the possible interrupted closefrom should be handled.
• we can share the code with closefrom case and non-closefrom case.

works with VSD-beta-478

One year later, I also did translation work for kleo and libkleo, which are pushed by Andre.
So, closing this task.

Fixed in 2.5.3.

glad it was useful!

Tested with the VSD beta 478. Works

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.

In T2169#196673, @werner wrote:

Shall we handle this with additional retry prompts, w/o a timeout? I think this makes sense because creating keys with a backup file and a passphrase is a manual task anyway.

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:

Thank you for your report.

Fixed in rA69069bc63e6b: Remove an declaration for an unused function.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

Also works in VSD-beta-478

Backported for VSD 3.3

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.

GpgEX requires/uses Kleopatra so that only GnuPG would be left if you could deselect Kleopatra. And that's exactly what the simple installer installs because the simple installer is included in the Gpg4win installer.

FYI usually these are my install options:

No problem. I can stay on 4.4.x. Just thought I should give the beta a try and let you guys know.

Thanks for your feedback. Maybe the "minimal" install is missing a file. It's a beta version for a reason. We'll make sure to fix it for the stable release.

None. I just use the command line tools and always perform a "minimal" install. @aheinecke: I already tested it on cmd.exe. Same result. Also I do not have QT installed, or a QT_PLUGIN_PATH set up. The bottom line for me is still:

Change the encryption code to only allow 256 bit session keys with Kyber regardless of the preferences, iff --require-pqc-encryption is set. […] We could as well also encforce AES-256 also without that option.

What if we encrypt to several recipients, only some of them having a Kyber encryption key? Should we still enforce AES-256 in that case regardless of the preferences, and assume that by now everybody should support AES-256?

Love it! I think I am going to use “post-heffalump crypto” from now on. :D

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

I wrote it with PQC security level in mind which requires AES256 for the session key as well.

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.

Here you are:

At gnupg/g10/pubkey-enc.c you will find

I have replaced the expiring test key with a new non-expiring test key.

Users landing here looking for help.

This looks like a bug with gnutls which is the only tool that fails :

Thank you. Fixed in: rPb415f3108921: build: Fix warning about obsolete pinentry-emacs.

What components of Gpg4win other than GnuPG do you use?

Yes, that's by design. GnuPG is always installed in $INSTDIR\..\GnuPG by the gpg4win installer.

Yeah that is a messed up environment mixing elf and windows binaries. There is no which on windows. It is called where. So if your terminal is able to execute which then this is some kind of Linux environment on Windows. The winpty error comes from the terminal. Please use cmd.exe for all tests.

I just tried to call pinentry directly on Windows cmd prompt:

Works. Tested with VS-Desktop-3.2.94.474-Beta and Gpg4win 4.4

Thanks for the comments. This is a regular git for Windows install which afaik uses mingw64. The messup with the binaries brought in by git has always been this way. I am using aliases to differentiate between the different versions. One might think that this may cause things to break, however all used to work well with 4.x versions.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Here you are:

This problem has gone in libgpg-error 1.51, since the implementation doesn't use environ any more.

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.