On the mailing list I wrote down my test results for en- and decrypting files (1-10 GB) with GnuPG and Gpg4win/Kleopatra. The encryption always ran with compression. Kleopatra needed more than 11 minutes to encrypt a file that is 10 GB big. Today I tested the encryption again but this time I added

compress-level 0

to gpg.conf (I also tried to add bzip2-compress-level 0 and then only compress-algo uncompressed because Bernhard was suggesting that in the mailing list but it made no difference).

Great! But as mentioned I would like to have a setting in Kleo to explicitly disable compression, GPGME_ENCRYPT_NO_COMPRESS. But that is a different task.

I am very sure that this is resolved and we support that in Kleopatra.

Thought about this for a while and rephrased and thus repopened.
I think it would be good to remove or explain the sha1sum checksums in the announcements.
Whether they are replaced by something else, e.g. sha256sum is of lesser importance.

Shouldn't we remove the sha1sum then as well? Or add an explanation?

Nope - too long for checking and introduces line wraps. Those who are not able to check digital signatures are also not able to properly handle checksum verification. On some platforms you don't even have a sha256sum tool. And they need to verify the mails first anyway. Note that for internal purposes we use sha256sum for years.

Reported by https://social.tchncs.de/@duxsco@digitalcourage.social/109546865597565084

Somehow I was waiting for such a comment ;-) Sure you are right and we will fix the README eventually.

This is probably not the right place, but considering you're telling people *here* that they should not build in the source tree, your README and INSTALL files do tell the users to do exactly that.

Thanks all. It is a bug in Win32 OpenSSH. https://github.com/PowerShell/Win32-OpenSSH/issues/1953 it is already fixed. I think the issue will be resolved after the update is shipped. I could use ssh -T git@github.com as a workaround.

Well, not our bug... it's a kind of support question and answer:
This might help: https://stackoverflow.com/questions/3844393/what-to-do-about-pty-allocation-request-failed-on-channel-0

Pushed the change.

This does not look like a problem in GnuPG/gpg4win because gnupg implements the ssh-agent protocol and not the ssh server or client functionality. ssh tells sshd whether it shall allocate a PTY (Pseudo TTY). I don't use ssh with github but it is likely that you may only run commands (which don't require a PTY). Usually you would invoke a "git" command cia ssh.

Authentication succeed if I pressed enter after:PTY allocation request failed on channel 0

I try WinGPG 4.1.0, and I receive an error:
ssh git@github.com
PTY allocation request failed on channel 0

I will push this change:

commit e89d57a2cb10bd04d266165015f159be2ab48984
Author: NIIBE Yutaka <gniibe@fsij.org>
Date:   Wed Dec 21 10:52:24 2022 +0900

Note that in-source-tree builds are broken - see T6313

You should do it for all software ;-).

Sorry, one more thing: I should use out of source builds for all gnupg software (libgpg-error, libksba, etc)? It's fine if so, just want to check what the policy is.

Ah, thanks! I didn't know this was unsupported. I'll change what we're doing.

You are building in the source tree - not a good idea. This should be supported but we don't test this. Please make your life easier and don't do build this way. We try to fix this for the next release.

Release done

To be released tomorrow.

@raysatiro: Please re-open if you are able to give us a reproducer

Fixed. Shall we backport this to gnupg22 ?

Thanks. Commited to master.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.