Re: clone vs submodule operation with HTTP cURL

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, May 16, 2017 at 8:15 PM, Jean-Francois Bouchard
<jfbouchard@accedian.com> wrote:
> Hello,
>
> Anyone can help with this ? The workaround is hardly possible in a
> medium environment as it needs editing and adding env to everyone and
> in every clone.

According to git-config anyauth is the default, see http.proxyAuthMethod.

Do you have something setting http.proxyAuthMethod in the environment
beforehand? What does:

    git config http.proxyAuthMethod

Return, in the same environment where your cloning fails? Same for
GIT_HTTP_PROXY_AUTHMETHOD.



> Thanks !!
> JF
>
> On Mon, May 15, 2017 at 5:38 PM, Jean-Francois Bouchard
> <jfbouchard@accedian.com> wrote:
>> Hello,
>>
>> Follow-up to this post.
>>
>> I seems that setting GIT_HTTP_PROXY_AUTHMETHOD=anyauth is a workaround
>> to this issue.
>>
>> So now the issue is : git is not setting AUTHMETHOD correctly when
>> doing a submodule update
>>
>> Note that a user is needed in the URL string. :@ does not work,
>> empty.auth variable does not work.
>>
>> Any ideas ?
>>
>> Thanks,
>> JF
>>
>> On Thu, May 11, 2017 at 6:04 PM, Jean-Francois Bouchard
>> <jfbouchard@accedian.com> wrote:
>>> Hello everyone,
>>>
>>> In our usage of GSSAPI via HTTPS, all our operation with git are very
>>> well handle, however, when trying to update a submodule, git seems to
>>> be managing cURL differently. cURL drop the ball quickly.
>>>
>>> Example (No other setup needed on the client) :
>>> git clone HTTPrepo -> GET -> 401 -> GET -> 401 -> GET (this time with
>>> Authorization: Negotiate)  -> 200 OK
>>>
>>> git submodule update -> GET -> 401 -> git prompt for username
>>>
>>> Is the codepath for clone regarding cURL is different than with submodule ?
>>>
>>> Using : 2.13.0, I have also tried the emptyAuth stuff with no avail.
>>>
>>> Thanks,
>>> JF
>
> --
>
>
> Avis de confidentialité
>
> Les informations contenues dans le présent message et dans toute pièce qui
> lui est jointe sont confidentielles et peuvent être protégées par le secret
> professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> plait communiquer immédiatement avec l’expéditeur et en détruire tout
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> Merci.
>
> Confidentiality notice
>
> This e-mail message and any attachment hereto contain confidential
> information which may be privileged and which is intended for the exclusive
> use of its addressee(s). If you receive this message in error, please
> inform sender immediately and destroy any copy thereof. Furthermore, any
> disclosure, distribution or copying of this message and/or any attachment
> hereto without the consent of the sender is strictly prohibited. Thank you.