Bug with bash and OpenSSL usage on Windows

  What did you do before the bug happened? (Steps to reproduce your issue)
Tried to generate a self-signed certificate using git bash.

Using git bash, I ran ``` openssl genrsa -aes256 (private key location) 4096 ``` however, openssl just hung (on Windows). Cmd can execute this command, but bash cannot.

What did you expect to happen? (Expected behavior)

openssl to generate messages about key generation to stdout

What happened instead? (Actual behavior)

openssl just hung

What's different between what you expected and what actually happened?

openssl just hung, rendering it unusable within bash Windows

Anything else you want to add:

This is an issue specifically with Windows x64.

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.45.2.windows.1 cpu: x86_64 built from commit: 91d03cb2e4fbf6ad961ace739b8a646868cb154d sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh feature: fsmonitor--daemon uname: Windows 10.0 19044 compiler info: gnuc: 14.1 libc info: no libc information available $SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

[Enabled Hooks] not run from a git repository - no hooks to show

user@(computer) MINGW64 ~ $ echo "I can start OpenSSL with no problem" I can start OpenSSL with no problem

user@(computer) MINGW64 ~ $ openssl help:

Standard commands asn1parse ca ciphers cmp cms crl crl2pkcs7 dgst dhparam dsa dsaparam ec ecparam enc engine errstr fipsinstall gendsa genpkey genrsa help info kdf list mac nseq ocsp passwd pkcs12 pkcs7 pkcs8 pkey pkeyparam pkeyutl prime rand rehash req rsa rsautl s_client s_server s_time sess_id smime speed spkac srp storeutl ts verify version x509

Message Digest commands (see the `dgst' command for more details) blake2b512 blake2s256 md4 md5 mdc2 rmd160 sha1 sha224 sha256 sha3-224 sha3-256 sha3-384 sha3-512 sha384 sha512 sha512-224 sha512-256 shake128 shake256 sm3

Cipher commands (see the `enc' command for more details) aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb aes-256-cbc aes-256-ecb aria-128-cbc aria-128-cfb aria-128-cfb1 aria-128-cfb8 aria-128-ctr aria-128-ecb aria-128-ofb aria-192-cbc aria-192-cfb aria-192-cfb1 aria-192-cfb8 aria-192-ctr aria-192-ecb aria-192-ofb aria-256-cbc aria-256-cfb aria-256-cfb1 aria-256-cfb8 aria-256-ctr aria-256-ecb aria-256-ofb base64 bf bf-cbc bf-cfb bf-ecb bf-ofb camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb camellia-256-cbc camellia-256-ecb cast cast-cbc cast5-cbc cast5-cfb cast5-ecb cast5-ofb des des-cbc des-cfb des-ecb des-ede des-ede-cbc des-ede-cfb des-ede-ofb des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb des-ofb des3 desx idea idea-cbc idea-cfb idea-ecb idea-ofb rc2 rc2-40-cbc rc2-64-cbc rc2-cbc rc2-cfb rc2-ecb rc2-ofb rc4 rc4-40 rc5 rc5-cbc rc5-cfb rc5-ecb rc5-ofb seed seed-cbc seed-cfb seed-ecb seed-ofb sm4-cbc sm4-cfb sm4-ctr sm4-ecb sm4-ofb zlib

user@(computer) MINGW64 ~ $ echo "However, if I run it, it just hangs" However, if I run it, it just hangs

user@(computer) MINGW64 ~ $ openssl genrsa -aes256 -out out

On Sat, 27 Jul 2024 at 05:40, Tim Abdiukov <tabdiukov@gmail.com> wrote:

Hey,

On 2024-07-26 at 19:40:48, Tim Abdiukov wrote:

The Git project doesn't ship OpenSSL, or, for that matter, any binaries at all. All we ship is source versions of Git which various distributors compile, sometimes with other binaries.

It looks like you're probably using Git for Windows, which _does_ ship OpenSSL, and so you probably want to contact them using their issue tracker[0] once you've verified that it hasn't already been reported.

[0] https://github.com/git-for-windows/git

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

Thanks for giving a response like the above, tirelessly every time something similar pops out.

I've been wondering if we can somehow reduce the occurrence of such an issue in the first place. Elaborating a bit more in the "Reporting bugs" section of the documentation landing page is probably the 0-th step, and if people agree that it is going in the right direction, perhaps we would extend it to include something similar to the top of the "git bugreport" template, by futzing with the implementation of builtin/bugreport.c:get_bug_template(), and we can even encourage customizing it by distribution.

Comments?

Thanks.

 Documentation/git.txt | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

Junio C Hamano <gitster@pobox.com> writes:

I forgot to mention that this weather-balloon patch was primarily to show the shape of the documentation updates, and corrections to use more appropriate URLs or additions for other binary distributors are of course welcome.

Thanks.

On Sat, Jul 27, 2024 at 11:53 AM Junio C Hamano <gitster@pobox.com> wrote:

In case this ever gets turned into a real patch...

 s/Windoes/Windows/

On 2024-07-27 at 15:53:06, Junio C Hamano wrote:

I think something like that would be valuable. We of course want to hear about useful bug reports, but there's nothing we can do in this case and it would be very helpful both for us and the reporter if it went to the right place at first (even if that were the case even just a slightly higher percentage of the time).

It might be helpful to maybe add a note that the reporter should search for a similar issue first before reporting it. I feel like Dscho, as well as the Debian and Ubuntu maintainers, will appreciate that, and I know for Ubuntu at least the issue tracker actually keeps track of the issues affecting the most people to help prioritize fixes.

On Sat, Jul 27, 2024 at 08:53:06AM -0700, Junio C Hamano wrote:

People might also get here from:

  https://git-scm.com/community

That page does mention the Git for Windows tracker, but it could perhaps be more explicit that "bundled" components are specific to Git for Windows. I don't really touch that site anymore, but I'm sure a pull request at:

  https://github.com/git/git-scm.com

would be welcome.

-Peff

Hi Tim,

I suspect that you also reported this issue at https://github.com/git-for-windows/git/issues/5079. For the benefit of readers of this list, here is the explanation:

`openssl.exe` is a pure Win32 program, while Git Bash uses a friendly fork of the Cygwin POSIX emulation layer. The latter, therefore, uses emulated pseudo terminals, but Win32 programs only use Win32 Consoles.

For the moment, therefore, programs like `openssl.exe` that want to interact with the user via such a Win32 Console have to be called via the `winpty` helper that acts as a translator between Win32 Consoles and emulated Unix pseudo terminals.

Modern Windows versions support a concept called "pseudo consoles" that are similar to Unix pseudo terminals, similar enough that there is an option to use them, which would avoid the need for that `winpty` helper.

In the near future, the Git for Windows project will switch the default to use those pseudo consoles by default (where available, that is).

Ciao, Johannes

On Sat, 27 Jul 2024, Tim Abdiukov wrote: