Re: clone vs submodule operation with HTTP cURL
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. Thanks !! JF On Mon, May 15, 2017 at 5:38 PM, Jean-Francois Bouchard <jfbouch...@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 > <jfbouch...@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.
Re: clone vs submodule operation with HTTP cURL
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 <jfbouch...@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.
clone vs submodule operation with HTTP cURL
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.
Re: Git + mod_auth_kerb
Hello, Thanks for this info. This make a lot of sense system wise. For a user point of view, it is a nightmare. Also, this break a lot of tools that are waiting username/password authentication via HTTPS. (I name Eclipse). Also, I m not able to reproduce the kerberos login on Ubuntu 14.04. I m asked to enter password even if a kerberos ticket is present and this even when I've embedded the username in the URI. Is there a better way to integrate Kerberos via HTTPS for git ? Thanks, JF On Mon, Jul 21, 2014 at 7:17 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jul 21, 2014 at 05:06:50PM -0400, Jean-Francois Bouchard wrote: Hello, We are currently working on a single sign on setup for our git install. We are using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the server side. Here some scenario we are trying to accomplish : -Without Kerberos ticket stored. Git ask for username/password. Result = Authentication failed -Kerberos ticket in store and BAD password : Git ask for username/password. Result = Authentication failed -Kerberos ticket in Store entering good password : Git ask for username/password. Result = Authentication failed on some host, other works -Kerberos ticket in Store and embedding the username in the URI (aka https://username@repo) Git don't ask for anything or ask for password Result = Works on some host, other request the password. (Will fail if the kerberos ticket not in store) So git uses libcurl with CURLAUTH_ANY. In order for authentication to work with libcurl, you have to supply a username. If you specify it in the URL, the libcurl realizes that it can use Kerberos, and goes on its merry way. If you don't specify the username in the URL, git notices that authentication has failed, and asks the credential store for a username and password. git does not know that a password is not needed, so the credential subsystem prompts for one anyway. I have mod_auth_kerb set up against Apache 2.4.9 at the moment, although I've used 2.2 before. I always use a username in the URL, and if I get prompted for the password, I just Ctrl-C out and run kinit before pushing again. I don't have mod_auth_kerb set up to fall back to basic auth, but if you do, using a username and password should work properly. You can use set the environment variable GIT_CURL_VERBOSE to 1 to see more information about what's actually going over the wire. This is a very strange behaviour. It seems to be cause by the way libcurl and git interact and the way the authentication goes (Negociate first, then basic auth). I have tried to use the helper to store invalid authentication information. With not much success. libcurl will always prefer something (anything) over basic auth, since basic auth is completely insecure unless you're using HTTPS. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -- 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git + mod_auth_kerb
Hello, We are currently working on a single sign on setup for our git install. We are using git 2.0.2 (ubuntu) plus apache/2.2.22 mod_auth_kerb on the server side. Here some scenario we are trying to accomplish : -Without Kerberos ticket stored. Git ask for username/password. Result = Authentication failed -Kerberos ticket in store and BAD password : Git ask for username/password. Result = Authentication failed -Kerberos ticket in Store entering good password : Git ask for username/password. Result = Authentication failed on some host, other works -Kerberos ticket in Store and embedding the username in the URI (aka https://username@repo) Git don't ask for anything or ask for password Result = Works on some host, other request the password. (Will fail if the kerberos ticket not in store) This is a very strange behaviour. It seems to be cause by the way libcurl and git interact and the way the authentication goes (Negociate first, then basic auth). I have tried to use the helper to store invalid authentication information. With not much success. Any idea ? 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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
