22

The following error appears when I try to clone git repository. I have the rsa public keys configured properly as well.

$ git clone https://github.com/blah/blah.git
Initialized empty Git repository in /home/arun/.git/
error: gnutls_handshake() failed: A TLS packet with unexpected length was
       received. while accessing https://github.com/blah/blah.git/info/refs

fatal: HTTP request failed
Mat
  • 188,820
  • 38
  • 367
  • 383
Arun Jayapal
  • 437
  • 1
  • 4
  • 12

6 Answers6

8

It could be used to a GnuTLs or pycurl bug

The following is the new method for pycurl_7.19.0-4ubuntu3:

sudo apt-get install build-essential fakeroot dpkg-dev
mkdir ~/python-pycurl-openssl
cd ~/python-pycurl-openssl
sudo apt-get source python-pycurl
sudo apt-get build-dep python-pycurl
sudo apt-get install libcurl4-openssl-dev
sudo dpkg-source -x pycurl_7.19.0-4ubuntu3.dsc
cd pycurl-7.19.0
# remove the HAVE_CURL_GNUTLS=1 in the following file
sudo vim debian/patches/10_setup.py.dpatch
# remove the HAVE_CURL_GNUTLS=1 in the following file
sudo vim setup.py
# replace all gnutls into openssl in the following file
sudo vim debian/control
sudo dpkg-buildpackage -rfakeroot -b
sudo dpkg -i ../python-pycurl_7.19.0-4ubuntu3_amd64.deb
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Thanks for sharing this. During the last step, I get the following error. Do you have any clues? $ sudo dpkg -i ../python-pycurl_7.19.0-4ubuntu3_amd64.deb dpkg: error processing ../python-pycurl_7.19.0-4ubuntu3_amd64.deb (--install): cannot access archive: No such file or directory Errors were encountered while processing: ../python-pycurl_7.19.0-4ubuntu3_amd64.deb – Arun Jayapal Nov 23 '12 at 10:14
  • 1
    @user1514027 I suppose it depends on the exact `.deb` file name built by the previous step (the `dpkg-buildpackage`). You need to have a look and search for the actual name generated. – VonC Nov 23 '12 at 10:16
  • I followed this solution, deviations included the source source file presenting as pycurl_7.19.0-3.dsc instead of pycurl_7.19.0-4ubuntu3.dsc. I also found it necessary to NOT edit patch file, doing so caused an MD5 failure on the build. – 2NinerRomeo Feb 07 '13 at 18:54
  • 1
    In the end, the behavior is unchanged, perhaps I need to find a way to really stop that macro from being defined. Perhaps I can manually make the changes to setup.py and stop the patch from being applied? – 2NinerRomeo Feb 07 '13 at 18:56
  • Edited the patched setup.py to remove the macro definition, then deleted the patched file and removed reference in /debian/patches/00list. Build appeared to work, but no change in behavior still. Dang. Would my certificate failing cause a similar problem? – 2NinerRomeo Feb 07 '13 at 19:05
  • @2NinerRomeo I didn't find any new information about that thread, so I will be interested with what you will come up. – VonC Feb 07 '13 at 19:45
  • Added an answer for what finally worked for me. I'm not sure how to distinguish whether I am using pycurl or not. – 2NinerRomeo Feb 26 '13 at 22:33
  • In my case, I get an error on fetching source for python-pycurl - `E: Unable to find a source package for pycurl` - http://hastebin.com/axezunupoz.mel – nsane Mar 01 '15 at 05:19
7

I had this problem, and it took me a while to find the solution. I kept thinking that I was missing a package somewhere. I didn't want to recompile Git, since I was already using the latest version, and I was pretty sure that the problem wasn't Git itself.

My problem was my .gitconfig file. The problem only occurred on an old Linux server that had been upgraded many times over the years. At some point, for some reason I don't recall, I had explicitly specified sslVersion = sslv3 in my .gitconfig file.

When I saw that, the lightbulb went on, since I know that SSL V3 has been deprecated due to security concerns, and that most people should be using TLS instead. For instance, see RFC 7568, https://tools.ietf.org/html/rfc7568

So my fix involved either deleting the offending sslVersion = sslv3 line from my ~/.gitconfig file, or changing this:

[httpd] 
    sslVersion = sslv3

to this:

[httpd]
    sslVersion = tlsv1.2

Removing the line and letting Git/libcurl negotiate the encryption seemed like the best choice, since TLS v1.3 is in the works, and I don't want to encounter this problem again in the future!

m0j0
  • 2,642
  • 4
  • 24
  • 32
  • 1
    Good suggestion. There are a number of [git-config options](https://git-scm.com/docs/git-config#git-config-httpsslVersion) that might lead to an issue like this or could be used as a work around. – 7yl4r May 22 '18 at 18:33
4

In My case, It appears I was not using pycurl, so the above solution did not work for me. What DID work was a rebuild of git-core modified to use openssl instead of gnutls.

Instructions are here:

https://askubuntu.com/questions/186847/error-gnutls-handshake-falied

I had substitute "git-core" for "git" in most places, the .dsc (package information file?) turned up as git-core_1.7.0.4-1ubuntu0.2.dsc, and the .deb package came out as git-core_1.7.0.4-1ubuntu0.2_i386.deb.

Community
  • 1
  • 1
2NinerRomeo
  • 2,431
  • 4
  • 22
  • 35
1

I've had the same problem when tried sudo git fetch from a directory my own user didn't have enough rights to. I moved repository to /tmp and continued my work.

Don't forget /tmp gets erased after reboot.

simno
  • 360
  • 7
  • 14
-1

For me, it ended up being that SSL certificate was self-signed. Give this a try

git config --global http.sslVerify false

Rick
  • 10,168
  • 2
  • 38
  • 40
  • 4
    Never do this. It disables authentication on _every TLS connection_ ever made by `git`, removing protection against several kinds of attacks. – cjs Aug 07 '18 at 09:38
-1

In my case worked, mixing the solutions of @Rick and @m0j0

First execute these commands:

git config --global http.sslVerify false
git config --global http.sslVerify true

After add or modify ~/.gitconfig

nano ~/.gitconfig

Set this:

[httpd] 
    sslVersion = sslv3
onalbi
  • 2,059
  • 21
  • 34