Github unable to access SSL connect error

后端 未结 3 828
感动是毒
感动是毒 2020-12-24 01:27

I have been using git lots for the last few months. git push worked 12 hours ago now all attempts generate errors, with verbose it produces this:

GIT_CURL_V         


        
相关标签:
3条回答
  • 2020-12-24 01:51

    yum update -y worked for me to fix a fatal error when running git clone.

    0 讨论(0)
  • 2020-12-24 02:02

    Had the same experience as OP, occurring for same reasons (Github's crypto removal notice of TlsV1, along with using a machine with a very old linux + git).

    FWIW, if you find yourself on a very old version of linux, but you're stubbornly adamant you don't want to upgrade to a newer version of linux (hence instantly get a newer Git and all its deps), you could try build a newer Git, along with its dependencies from the source.

    It's a time-consuming and painful path, and probably upgrading your linux is easier than this, but oh well, I just wanted to stick with my old linux.

    I jotted a few notes of my attempt, hopefully it will help anyone that braves this path:

    • Git depended on openssl and curl, so I had to build those too
    • I had to upgrade my version of cmake in order to build the newer curl (building cmake took about 2-3 hours)
    • The newer cmake required me to build a newer gcc (which took about 21 hours to build on my old machine!)
    • Once I had cmake, I could build curl, but it referenced an older version of openssl (which did not have the newer TlsV1.2)
    • So I had to build a newer openssl, then followed by building curl (doing my utmost to assure the build referenced this newer openssl)
    • Then I could build Git, again, doing my best to assure it referenced the newer openssl and curl

    I found myself repeatedly using "ldd" to confirm the referenced libraries, as on many occasions, the build would reference the wrong one, and I'd have to figure out how to enforce my desired path.

    Some examples of this were:

    # ldd /opt/git-2.27.0/libexec/git-core/git-http-fetch | grep -E "libssl|libcrypto|libcurl"
            libcurl.so => /usr/local/lib/libcurl.so (0x00aed000)
            libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00e86000)
            libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00893000)
    

    This helped me confirm 'git-http-fetch" was making using of my newer curl (at /usr/local/lib, and not /usr/lib), and my newer openssl (at /usr/local/ssl/lib, and not /usr/lib)

    $ ldd /usr/local/bin/curl | grep -E "libssl|libcrypto"
            libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00110000)
            libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x0016f000)
    

    This helped me confirm that my new 'curl' was referencing newer openssl (at /usr/local/ssl/lib, and not /usr/lib)

    To enforce these paths, Git let you set these env-vars prior to building:

    OPENSSLDIR=/usr/local/ssl/
    CURLDIR=/usr/local/
    

    For curl, I had to pass the openssl path via cmake:

    cmake -DOPENSSL_ROOT_DIR=/usr/local/ssl .
    

    For cmake, it also referenced openssl, and I passed that path across on its 'bootstrap' step:

    ./bootstrap --prefix=/opt/cmake-3.17.3 -- -DOPENSSL_ROOT_DIR=/usr/local/ssl
    

    Apologies for the answer being all over the place. I can flesh it out with more detail if there is a request for it, but given that its taken me about a week to sort this out, I think most people will prefer the sane path of just upgrading your linux.

    0 讨论(0)
  • 2020-12-24 02:16

    I was having the same problem on various CentOS 6 VM's and it turned out to be an issue with stale curl and nss libraries (thanks to this thread for pointing me in the right direction: cURL SSL connect error 35 with NSS error -5961).

    The fix that worked for me is just:

    yum update -y nss curl libcurl
    
    0 讨论(0)
提交回复
热议问题