#1010340 git: Fails to clone and pull from existign repositories

Package:
git
Source:
git
Description:
fast, scalable, distributed revision control system
Submitter:
Andrea Palazzi
Date:
2023-02-28 15:39:03 UTC
Severity:
important
#1010340#5
Date:
2022-04-29 08:40:15 UTC
From:
To:
Dear Maintainer,

On my test system git is now basically unusable as it fails to clone and to pull from already cloned repositories with an error "error: git-remote-https died of signal 4"; e.g.:

andrea@test:~$ LC_ALL=C git clone --branch=14.0 https://github.com/OCA/manufacture.git
Cloning into 'manufacture'...
error: git-remote-https died of signal 4

I can clone the very same repository from Windows, so the remote is not the problem.

   * What led up to the situation?
A recent apt-upgrade, not sure when exactly it caused the issue.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
Effective: nothing
Ineffective: try to clone from root; uninstall and reinstall git; install git from unstable.

Please note that I added the unstable repository just to install git from there, but it's effectively a "bookworm" release.

Don't know if it's relevant, the system runs on a Qemu VM; but until recently git was working fine.
If you know how to enable more verbose messages from git or you want me to do some testing please let me know.

Andrea
#1010340#10
Date:
2022-04-29 22:57:51 UTC
From:
To:
Hi,

Andrea Palazzi wrote:

I can't reproduce this on Debian Unstable amd64:

/tmp → LC_ALL=C git clone --branch=14.0 https://github.com/OCA/manufacture.git
Cloning into 'manufacture'...
remote: Enumerating objects: 29001, done.
remote: Counting objects: 100% (1661/1661), done.
remote: Compressing objects: 100% (831/831), done.
remote: Total 29001 (delta 948), reused 1373 (delta 786), pack-reused 27340
Receiving objects: 100% (29001/29001), 8.43 MiB | 2.12 MiB/s, done.
Resolving deltas: 100% (19042/19042), done.
/tmp → git --version
git version 2.36.0
/tmp → lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux bookworm/sid
Release:        unstable
Codename:       sid

Maybe some hiccup at Github?

		Regards, Axel
#1010340#15
Date:
2022-05-02 19:40:49 UTC
From:
To:
Hi,

Thanks,Andrea
#1010340#20
Date:
2022-05-03 08:16:35 UTC
From:
To:
Hi,

Andrea Palazzi wrote:

And I was able to do so on Debian Sid.

So maybe a host-specific issue like a git setting in ~/.gitconfig or
.git/config which no more works (properly) with 2.36?

Thanks!

		Regards, Axel
#1010340#25
Date:
2022-05-04 11:37:45 UTC
From:
To:
Andrea Palazzi wrote:
ThanksAndrea
#1010340#30
Date:
2022-05-04 12:04:45 UTC
From:
To:
Hi Andrea,

Andrea Palazzi wrote:

Interesting find, thanks for these details!

Not sure, but it surely can be downgraded. Done so.

The question is (and I can't answer that) if Debian generally supports
running under these settings or if git has some (hopefully
deactivatable) optimizations which fail under these settings.

		Regards, Axel
#1010340#37
Date:
2022-05-29 11:19:42 UTC
From:
To:
I have unfortunately had to make the same experiences. with the accelerator hax or whpx it leads to the same error with QEMU (tested v6.2.x and
v7.0.x). Using tcg as accelerator is not an alternative, because it is extremely slow.

What I could find out so far is that it leads to an error with Ubuntu 20.04 LTS and 22.04 LTS. Also when updating git. Strangely, the error does not
appear with Ubuntu 21.04. Therefore, I recently thought to repeat the test with Ubuntu 22.04 LTS where I unfortunately found that the same error occurs.

What helps is compiling git with OpenSSL instead of GnuTLS (which is standard with git).

See also https://github.com/paul-nelson-baker/git-openssl-shellscript.

How could I get to the root cause of the error?

Regards,
Sascha
#1010340#42
Date:
2022-05-29 16:44:40 UTC
From:
To:
Apparently setting the GNUTLS_CPUID_OVERRIDE variable helps to work around the error. For more details please refer to this page.

https://gnutls.org/manual/html_node/Debugging-and-auditing.html

The error doesn't appear anymore when setting the GNUTLS_CPUID_OVERRIDE.
GNUTLS_CPUID_OVERRIDE=0x1 git clone https://...

With QEMU 7.0 and apt-get update the same error is also triggered, since also GnuTLS is used.
sudo GNUTLS_CPUID_OVERRIDE=0x1 apt-get update

So this is not really a bug in git, but a bug in GnuTLS when running QEMU with Windows as host (with Hyper-V acceleration hax or whpx).

Best,
Sascha

On Sun, 29 May 2022 13:19:42 +0200 Sascha Scandella <sascha.scandella@gmail.com> wrote:
 > I have unfortunately had to make the same experiences. with the accelerator hax or whpx it leads to the same error with QEMU (tested v6.2.x and
 > v7.0.x). Using tcg as accelerator is not an alternative, because it is extremely slow.
 >
 > What I could find out so far is that it leads to an error with Ubuntu 20.04 LTS and 22.04 LTS. Also when updating git. Strangely, the error does not
 > appear with Ubuntu 21.04. Therefore, I recently thought to repeat the test with Ubuntu 22.04 LTS where I unfortunately found that the same error
occurs.
 >
 > What helps is compiling git with OpenSSL instead of GnuTLS (which is standard with git).
 >
 > See also https://github.com/paul-nelson-baker/git-openssl-shellscript.
 >
 > How could I get to the root cause of the error?
 >
 > Regards,
 > Sascha
 >
 >
 >
#1010340#47
Date:
2022-10-07 13:48:44 UTC
From:
To:
 Hello,
My name is Chan Yeol, I sent a message to your email but I have not
received any response from you. So, I want to know if you received my
previous message.
Greetings.
#1010340#52
Date:
2023-02-28 15:34:38 UTC
From:
To:
Hi,

I have the same problem with a Debian GNU/Linux 11 (bullseye) on bare metal
(not QEMU).
It happens with all github repositories I've tried:

$ git clone https://github.com/esnet/iperf
Cloning into 'iperf'...
(never ends, or ends with "error: git-remote-https died of signal 8")

If I strace the process git-remote-https, it's doing getrandom() all the
time.
Setting GNUTLS_CPUID_OVERRIDE=0x1 doesn't solve it.
I don't have any .gitconfig or similar.

Regards,