2

While this is a common question, this one is particlary different than the others, when I issue git ls-remote https://myuser@bitbucket.org/myser/repo.git , it asks me for the password and gives me the result:

tomaz:~/ $ git ls-remote https://tcanabrava@bitbucket.org/tcanabrava/randrepo.git
Password: 
1c8cd7266ad19de952db096a0f25ee16dc3cdace        HEAD
1c8cd7266ad19de952db096a0f25ee16dc3cdace        refs/heads/master

but when I issue git clone...

tomaz:~/ $ $git clone https://tcanabrava@bitbucket.org/tcanabrava/randrepo.git
Cloning into 'felipao'...
Password: 
error: RPC failed; result=22, HTTP code = 401
fatal: The remote end hung up unexpectedly

And I'v already looked over and over on all google answers for this particular error and nothing could fix it.

  1. I'm sure that the address is correct, it lists the branches using ls-remote.
  2. already set the postBuffer = 52428800
  3. the proxies are fine, it lists the branches using ls-remote
  4. run with GIT_CURL_VERBOSE=1 too long to post here unfortunately =(
Tomaz Canabrava
  • 2,320
  • 15
  • 20

3 Answers3

1

With Git 2.18 (Q2 2018), you now have more control over curl as used by Git.

The HTTP client code used to advertise that Git accept gzip encoding from the other side; instead, just let cURL library to advertise and negotiate the best one.

See commit eaf6a1b, commit 1a53e69 (22 May 2018) by Brandon Williams (mbrandonw).
(Merged by Junio C Hamano -- gitster -- in commit 13e8be9, 30 May 2018)

remote-curl: accept all encodings supported by curl

Configure curl to accept all encodings which curl supports instead of only accepting gzip responses.

This fixes an issue when using an installation of curl which is built without the "zlib" feature. Since aa90b96 (Enable info/refs gzip decompression in HTTP client, 2012-09-19, Git 1.7.12.3) we end up requesting "gzip" encoding anyway despite libcurl not being able to decode it.
Worse, instead of getting a clear error message indicating so, we end up falling back to "dumb" http, producing a confusing and difficult to debug result.

Since curl doesn't do any checking to verify that it supports the a requested encoding, instead set the curl option CURLOPT_ENCODING with an empty string indicating that curl should send an "Accept-Encoding" header containing only the encodings supported by curl.

run with GIT_CURL_VERBOSE=1 too long to post here unfortunately

Before Git 2.28, that would not be safe to post here anyway for GIT_CURL_VERBOSE or GIT_TRACE_CURL.

With Git 2.28 (Q3 2020), rewrite support for GIT_CURL_VERBOSE in terms of GIT_TRACE_CURL.

See commit 7167a62, commit 373e9bd (11 May 2020) by Jonathan Tan (jhowtan).
(Merged by Junio C Hamano -- gitster -- in commit 0b925a4, 09 Jun 2020)

http, imap-send: stop using CURLOPT_VERBOSE

Signed-off-by: Jonathan Tan

Whenever GIT_CURL_VERBOSE is set, teach Git to behave as if GIT_TRACE_CURL=1 and GIT_TRACE_CURL_NO_DATA=1 is set, instead of setting CURLOPT_VERBOSE.

This is to prevent inadvertent revelation of sensitive data.

In particular, GIT_CURL_VERBOSE redacts neither the "Authorization" header nor any cookies specified by GIT_REDACT_COOKIES.

Unifying the tracing mechanism also has the future benefit that any improvements to the tracing mechanism will benefit both users of GIT_CURL_VERBOSE and GIT_TRACE_CURL, and we do not need to remember to implement any improvement twice.

Still with Git 2.28 (Q3 2020), the interface to redact sensitive information in the trace output has been simplified.

See commit 827e7d4 (05 Jun 2020) by Jonathan Tan (jhowtan).
(Merged by Junio C Hamano -- gitster -- in commit b8a5299, 22 Jun 2020)

http: redact all cookies, teach GIT_TRACE_REDACT=0

Signed-off-by: Jonathan Tan

In trace output (when GIT_TRACE_CURL is true), redact the values of all HTTP cookies by default.
Now that auth headers (since the implementation of GIT_TRACE_CURL in 74c682d3c6 ("[http.c](https://github.com/git/git/blob/827e7d4da470e8b9b222b2cf3b4a3b7f8c3c671f/http.c): implement the GIT_TRACE_CURL environment variable", 2016-05-24, Git v2.10.0-rc0 -- merge listed in batch #3)) and cookie values (since this commit) are redacted by default in these traces, also allow the user to inhibit these redactions through an environment variable.

Since values of all cookies are now redacted by default, GIT_REDACT_COOKIES (which previously allowed users to select individual cookies to redact) now has no effect.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

These are exact symptomps of a curl 7.28 bug. If you are using curl 7.28 downgrade it or switch to SSH auth until the fix comes out.

More info:

John T. Brown
  • 85
  • 4
0

I had similiar problem. I'm not sure what helped, but:

  1. I downgraded Curl to 7.25
  2. I changed URL format with .netrc (http://stackoverflow.com/questions/5796171/git-clone-over-https-401-error-and-not-asking-for-username-or-password/5810821#5810821)
  3. Everything is under git 1.7.10. I downgraded from 1.8.0-1 (pull and clone over WebDav just doesn't work in this version. As far as repos created with 1.7 are concerned. If someone know why, please write in a comment).
shark555
  • 2,562
  • 1
  • 20
  • 10