* forcing a user@ into the URL if not present @ 2015-04-22 20:06 Dan Langille 2015-04-30 20:14 ` Dan Langille 0 siblings, 1 reply; 10+ messages in thread From: Dan Langille @ 2015-04-22 20:06 UTC (permalink / raw) To: git Hello, I'm using git 2.3.2 with Kerberos for authentication and gito-lite for authorization. This works: $ git clone https://dvl@ repo.example.org/git/testing Cloning into 'testing'... warning: You appear to have cloned an empty repository. Checking connectivity... done. My goal: have it work without supplying dvl@ as shown here: $ git clone https://repo.example.org/git/testing Cloning into 'testing'... Username for 'https://repo.example.org': I don't want to be prompted for a password. I want Kerberos to kick in. Following http://git-scm.com/docs/gitcredentials, the following seems to have nil effect. Anyone used this feature already? git config --global credential.https://repo.example.org.username dvl $ cat ~/.gitconfig [credential "https://repo.example.org"] username = dvl [http] sslCAInfo = /usr/local/etc/trusted-certificates.pem With the above, I still get prompted for a password Given my use of Kerberos for authorization, is this option feasible? Should I be taking a different approach? Thank you. -- Dan Langille Infrastructure & Operations Talos Group Sourcefire, Inc. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-04-22 20:06 forcing a user@ into the URL if not present Dan Langille @ 2015-04-30 20:14 ` Dan Langille 2015-04-30 20:23 ` brian m. carlson 0 siblings, 1 reply; 10+ messages in thread From: Dan Langille @ 2015-04-30 20:14 UTC (permalink / raw) To: git Would this question be better suited for another list? On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote: > Hello, > > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for > authorization. > > This works: > > $ git clone https://dvl@ repo.example.org/git/testing > Cloning into 'testing'... > warning: You appear to have cloned an empty repository. > Checking connectivity... done. > > My goal: have it work without supplying dvl@ as shown here: > > $ git clone https://repo.example.org/git/testing > Cloning into 'testing'... > Username for 'https://repo.example.org': > > I don't want to be prompted for a password. I want Kerberos to kick in. > > Following http://git-scm.com/docs/gitcredentials, the following seems to > have nil effect. Anyone used this feature already? > > git config --global credential.https://repo.example.org.username dvl > > $ cat ~/.gitconfig > [credential "https://repo.example.org"] > username = dvl > [http] > sslCAInfo = /usr/local/etc/trusted-certificates.pem > > With the above, I still get prompted for a password > > Given my use of Kerberos for authorization, is this option feasible? > > Should I be taking a different approach? > > Thank you. > > -- > Dan Langille > Infrastructure & Operations > Talos Group > Sourcefire, Inc. -- Dan Langille Infrastructure & Operations Talos Group Sourcefire, Inc. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-04-30 20:14 ` Dan Langille @ 2015-04-30 20:23 ` brian m. carlson 2015-05-04 19:35 ` Dan Langille 0 siblings, 1 reply; 10+ messages in thread From: brian m. carlson @ 2015-04-30 20:23 UTC (permalink / raw) To: Dan Langille; +Cc: git [-- Attachment #1: Type: text/plain, Size: 2215 bytes --] On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote: > Would this question be better suited for another list? Nope, this is the place to go. > On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote: > > Hello, > > > > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for > > authorization. > > > > This works: > > > > $ git clone https://dvl@ repo.example.org/git/testing > > Cloning into 'testing'... > > warning: You appear to have cloned an empty repository. > > Checking connectivity... done. > > > > My goal: have it work without supplying dvl@ as shown here: > > > > $ git clone https://repo.example.org/git/testing > > Cloning into 'testing'... > > Username for 'https://repo.example.org': > > > > I don't want to be prompted for a password. I want Kerberos to kick in. > > > > Following http://git-scm.com/docs/gitcredentials, the following seems to > > have nil effect. Anyone used this feature already? > > > > git config --global credential.https://repo.example.org.username dvl > > > > $ cat ~/.gitconfig > > [credential "https://repo.example.org"] > > username = dvl > > [http] > > sslCAInfo = /usr/local/etc/trusted-certificates.pem > > > > With the above, I still get prompted for a password > > > > Given my use of Kerberos for authorization, is this option feasible? Not at the present time. The only time that the credential API is invoked is if it prompts for a password, and by that point you've fallen back to Basic authentication. > > Should I be taking a different approach? If you want it to work only with Kerberos, then any username in the URL is fine, as libcurl doesn't care. One thing you could try is to make your URL https://git@repo.example.org and then use git config --global credential.https://git@repo.example.org.username dvl and see if it does the right thing for both Kerberos and Basic auth. It would be sort of a hack, but it might work. -- 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-04-30 20:23 ` brian m. carlson @ 2015-05-04 19:35 ` Dan Langille 2015-05-05 12:35 ` Dan Langille 0 siblings, 1 reply; 10+ messages in thread From: Dan Langille @ 2015-05-04 19:35 UTC (permalink / raw) To: brian m. carlson, Dan Langille, git On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson <sandals@crustytoothpaste.net> wrote: > On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote: >> Would this question be better suited for another list? > > Nope, this is the place to go. > >> On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote: >> > Hello, >> > >> > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for >> > authorization. >> > >> > This works: >> > >> > $ git clone https://dvl@ repo.example.org/git/testing >> > Cloning into 'testing'... >> > warning: You appear to have cloned an empty repository. >> > Checking connectivity... done. >> > >> > My goal: have it work without supplying dvl@ as shown here: >> > >> > $ git clone https://repo.example.org/git/testing >> > Cloning into 'testing'... >> > Username for 'https://repo.example.org': >> > >> > I don't want to be prompted for a password. I want Kerberos to kick in. >> > >> > Following http://git-scm.com/docs/gitcredentials, the following seems to >> > have nil effect. Anyone used this feature already? >> > >> > git config --global credential.https://repo.example.org.username dvl >> > >> > $ cat ~/.gitconfig >> > [credential "https://repo.example.org"] >> > username = dvl >> > [http] >> > sslCAInfo = /usr/local/etc/trusted-certificates.pem >> > >> > With the above, I still get prompted for a password >> > >> > Given my use of Kerberos for authorization, is this option feasible? > > Not at the present time. The only time that the credential API is > invoked is if it prompts for a password, and by that point you've fallen > back to Basic authentication. > >> > Should I be taking a different approach? > > If you want it to work only with Kerberos, then any username in the URL > is fine, as libcurl doesn't care. That is what I found during testing. So long as I put a username in the URL, Kerberos worked and all authentication occurred as expected. >> One thing you could try is to make your URL https://git@repo.example.org > and then use > > git config --global credential.https://git@repo.example.org.username dvl > > and see if it does the right thing for both Kerberos and Basic auth. It > would be sort of a hack, but it might work. It asks for a password, and for the correct user: Password for 'https://dvl@repo.example.org': Thanks Brian, for this, and your other help. I appreciate it. -- Dan Langille Infrastructure & Operations Talos Group Sourcefire, Inc. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-04 19:35 ` Dan Langille @ 2015-05-05 12:35 ` Dan Langille 2015-05-05 13:59 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Dan Langille @ 2015-05-05 12:35 UTC (permalink / raw) To: brian m. carlson, Dan Langille, git On Mon, May 4, 2015 at 3:35 PM, Dan Langille <dlangille@sourcefire.com> wrote: > On Thu, Apr 30, 2015 at 4:23 PM, brian m. carlson > <sandals@crustytoothpaste.net> wrote: >> On Thu, Apr 30, 2015 at 04:14:12PM -0400, Dan Langille wrote: >>> Would this question be better suited for another list? >> >> Nope, this is the place to go. >> >>> On Wed, Apr 22, 2015 at 4:06 PM, Dan Langille <dlangille@sourcefire.com> wrote: >>> > Hello, >>> > >>> > I'm using git 2.3.2 with Kerberos for authentication and gito-lite for >>> > authorization. >>> > >>> > This works: >>> > >>> > $ git clone https://dvl@ repo.example.org/git/testing >>> > Cloning into 'testing'... >>> > warning: You appear to have cloned an empty repository. >>> > Checking connectivity... done. >>> > >>> > My goal: have it work without supplying dvl@ as shown here: >>> > >>> > $ git clone https://repo.example.org/git/testing >>> > Cloning into 'testing'... >>> > Username for 'https://repo.example.org': >>> > >>> > I don't want to be prompted for a password. I want Kerberos to kick in. >>> > >>> > Following http://git-scm.com/docs/gitcredentials, the following seems to >>> > have nil effect. Anyone used this feature already? >>> > >>> > git config --global credential.https://repo.example.org.username dvl >>> > >>> > $ cat ~/.gitconfig >>> > [credential "https://repo.example.org"] >>> > username = dvl >>> > [http] >>> > sslCAInfo = /usr/local/etc/trusted-certificates.pem >>> > >>> > With the above, I still get prompted for a password >>> > >>> > Given my use of Kerberos for authorization, is this option feasible? >> >> Not at the present time. The only time that the credential API is >> invoked is if it prompts for a password, and by that point you've fallen >> back to Basic authentication. >> >>> > Should I be taking a different approach? >> >> If you want it to work only with Kerberos, then any username in the URL >> is fine, as libcurl doesn't care. > > That is what I found during testing. So long as I put a username in > the URL, Kerberos worked > and all authentication occurred as expected. As I understand it, in order to invoke Kerberos Authentication, a username must be in the URL, but that username is not involved in the authentication process. Thus, the username in the config is never applied to any URL and does not not work the same way as a username which appears in the URL. I suspect this is because a username in the URL invokes authentication, which prompts the whole Kerberos process. The best workaround I've found is this configuration item: [url "https://FOO@repo.example.org"] insteadOf = https://repo.example.org We'd be happy if we could set this as a global config setting and not have the users prompted for a password. The whole beauty of Kerberos is not getting prompted for stuff. Am I simply failing to comprehend the steps involved in Kerberos Authentication? What bits of code would need looking at in order for git authentication to work seamlessly with Kerberos? We are so close. -- Dan Langille Infrastructure & Operations Talos Group Sourcefire, Inc. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-05 12:35 ` Dan Langille @ 2015-05-05 13:59 ` Johannes Schindelin 2015-05-05 17:45 ` Junio C Hamano 0 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2015-05-05 13:59 UTC (permalink / raw) To: Dan Langille; +Cc: brian m. carlson, git Hi Dan, On 2015-05-05 14:35, Dan Langille wrote: > As I understand it, in order to invoke Kerberos Authentication, a > username must be in the URL, but that username is not involved in the > authentication process. Having stumbled over [this ticket](https://github.com/git-for-windows/git/issues/92) recently, it appears to me as if the following should work for you: git clone https://:@repo.example.org/ Ciao, Johannes ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-05 13:59 ` Johannes Schindelin @ 2015-05-05 17:45 ` Junio C Hamano 2015-05-06 4:52 ` Torsten Bögershausen 0 siblings, 1 reply; 10+ messages in thread From: Junio C Hamano @ 2015-05-05 17:45 UTC (permalink / raw) To: Johannes Schindelin, Torsten Bögershausen Cc: Dan Langille, brian m. carlson, git Johannes Schindelin <johannes.schindelin@gmx.de> writes: > Having stumbled over [this > ticket](https://github.com/git-for-windows/git/issues/92) recently, it > appears to me as if the following should work for you: > > git clone https://:@repo.example.org/ Wow. Is this a windows-only SSPI thing, or is this a widely accepted URL convention? I haven't seen anybody use such a URL but I would say that is a natural thing to expect to work, as both username and password are missing so they should default to some sensible values, in this case "current user, shouldn't need password", just like "scheme://site:/" is "port missing so it should default to some sensible value, appropriate for the scheme". I think Torsten recently added a bit more test for our URL parsing code, especially for "scheme://site:/" (missing port), but I do not think we have "scheme://:site/" (missing user or password). Perhaps we would want to have additional tests to cover this shape of URL? Thanks. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-05 17:45 ` Junio C Hamano @ 2015-05-06 4:52 ` Torsten Bögershausen 2015-05-06 5:29 ` Johannes Schindelin 0 siblings, 1 reply; 10+ messages in thread From: Torsten Bögershausen @ 2015-05-06 4:52 UTC (permalink / raw) To: Junio C Hamano, Johannes Schindelin, Torsten Bögershausen Cc: Dan Langille, brian m. carlson, git On 05/05/2015 07:45 PM, Junio C Hamano wrote: > Johannes Schindelin <johannes.schindelin@gmx.de> writes: > >> Having stumbled over [this >> ticket](https://github.com/git-for-windows/git/issues/92) recently, it >> appears to me as if the following should work for you: >> >> git clone https://:@repo.example.org/ > Wow. > > Is this a windows-only SSPI thing, or is this a widely accepted URL > convention? I haven't seen anybody use such a URL but I would say > that is a natural thing to expect to work, as both username and > password are missing so they should default to some sensible values, > in this case "current user, shouldn't need password", just like > "scheme://site:/" is "port missing so it should default to some > sensible value, appropriate for the scheme". > > I think Torsten recently added a bit more test for our URL parsing > code, especially for "scheme://site:/" (missing port), but I do not > think we have "scheme://:site/" (missing user or password). Perhaps > we would want to have additional tests to cover this shape of URL? > I have added tests for URL parsing, but for host names/port numbers. Not for usernames/passwords (passwords shouldn't be there, recommends RFC 3986) And only for the ssh:// protocol, as well as git://. http:// and https:// are not handled by connect.c at all, and I'm not really familiar with curl, nor kerberos. In other words: I can not help very much at the moment. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-06 4:52 ` Torsten Bögershausen @ 2015-05-06 5:29 ` Johannes Schindelin 2015-05-06 17:18 ` Junio C Hamano 0 siblings, 1 reply; 10+ messages in thread From: Johannes Schindelin @ 2015-05-06 5:29 UTC (permalink / raw) To: Torsten Bögershausen Cc: Junio C Hamano, Dan Langille, brian m. carlson, git Hi Torsten & Junio, On 2015-05-06 06:52, Torsten Bögershausen wrote: > On 05/05/2015 07:45 PM, Junio C Hamano wrote: >> Johannes Schindelin <johannes.schindelin@gmx.de> writes: >> >>> Having stumbled over [this >>> ticket](https://github.com/git-for-windows/git/issues/92) recently, it >>> appears to me as if the following should work for you: >>> >>> git clone https://:@repo.example.org/ >> >> Wow. My reaction exactly. >> Is this a windows-only SSPI thing, or is this a widely accepted URL convention? Quite frankly, I have no idea. Before reading that ticket, I did not even think of trying such a convention. >> I haven't seen anybody use such a URL but I would say that is a natural thing to expect to work, as both username and password are missing so they should default to some sensible values, in this case "current user, shouldn't need password", just like "scheme://site:/" is "port missing so it should default to some sensible value, appropriate for the scheme". Yes, that makes total sense to me, too. In fact, I found it rather clever once I got over the surprise. >> I think Torsten recently added a bit more test for our URL parsing >> code, especially for "scheme://site:/" (missing port), but I do not >> think we have "scheme://:site/" (missing user or password). Perhaps >> we would want to have additional tests to cover this shape of URL? >> > I have added tests for URL parsing, but for host names/port numbers. > Not for usernames/passwords (passwords shouldn't be there, > recommends RFC 3986) > > And only for the ssh:// protocol, as well as git://. > http:// and https:// are not handled by connect.c at all, > and I'm not really familiar with curl, nor kerberos. TBH it does not seem overly urgent to add those tests for the HTTPS handling. From a cursory look it seems that neither `transport_helper_init()` nor any code in `remote-curl.c` parses the "<user@password>" part of the URL, or for that matter puts restrictions on it. The issue I linked to was with a cURL that was compiled without support for the particular authentication method configured for the credential helper. So I fear that testing the KERBEROS support would be the duty of an integration test (which we do not have so far) rather than a unit test. Ciao, Dscho ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: forcing a user@ into the URL if not present 2015-05-06 5:29 ` Johannes Schindelin @ 2015-05-06 17:18 ` Junio C Hamano 0 siblings, 0 replies; 10+ messages in thread From: Junio C Hamano @ 2015-05-06 17:18 UTC (permalink / raw) To: Johannes Schindelin Cc: Torsten Bögershausen, Dan Langille, brian m. carlson, git Johannes Schindelin <johannes.schindelin@gmx.de> writes: >>> I haven't seen anybody use such a URL but I would say that is a >>> natural thing to expect to work, as both username and password are >>> missing so they should default to some sensible values, in this >>> case "current user, shouldn't need password", just like >>> "scheme://site:/" is "port missing so it should default to some >>> sensible value, appropriate for the scheme". > > Yes, that makes total sense to me, too. In fact, I found it rather > clever once I got over the surprise. Yup, I'd happily call that "clever" ;-) > TBH it does not seem overly urgent to add those tests for the HTTPS > handling. From a cursory look it seems that neither > transport_helper_init()` nor any code in `remote-curl.c` parses the > "<user@password>" part of the URL, or for that matter puts > restrictions on it. Thanks for checking. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-05-06 17:18 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-22 20:06 forcing a user@ into the URL if not present Dan Langille 2015-04-30 20:14 ` Dan Langille 2015-04-30 20:23 ` brian m. carlson 2015-05-04 19:35 ` Dan Langille 2015-05-05 12:35 ` Dan Langille 2015-05-05 13:59 ` Johannes Schindelin 2015-05-05 17:45 ` Junio C Hamano 2015-05-06 4:52 ` Torsten Bögershausen 2015-05-06 5:29 ` Johannes Schindelin 2015-05-06 17:18 ` Junio C Hamano
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.