# HTTP basic authentication support 8 messages from 2005-11-20 to 2005-11-24. Participants: Kalle Valo, Junio C Hamano, Krzysztof Halasa, Johannes Schindelin. Thread: https://gitlist.dev/t/2610 ## Kalle Valo, 2005-11-20 08:38 Subject: HTTP basic authentication support Message-ID: <87u0e71zpx.fsf@litku.valo.iki.fi> URL: https://gitlist.dev/e/87u0e71zpx.fsf%40litku.valo.iki.fi ``` I keep some personal files in a git repository. Now I want to have the repository in an HTTP server so that I can access it everywhere I go. Since I don't want to share the repository with the whole world, I would like to use the HTTP basic authentication, just to give a little protection. But it seems that git doesn't support it, yet. Or did I miss something? I made a test repository which requires basic authentication. Login is foo and password bar. git clone doesn't work: $ git clone http://foo:bar@www.valo.iki.fi/kalle/tmp/auth.git/ auth defaulting to local storage area Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? $ But curl works: $ curl http://foo:bar@www.valo.iki.fi/kalle/tmp/auth.git/info/refs 4cb663bd2b92d57c5e1ba0bfa9bf65c2e50ff46a refs/heads/master $ I'm using git updated an hour ago. -- Kalle Valo ``` ## Kalle Valo, 2005-11-20 10:05 Subject: [PATCH] Support username and password inside URL Message-ID: <873blriqh0.fsf@litku.valo.iki.fi> URL: https://gitlist.dev/e/873blriqh0.fsf%40litku.valo.iki.fi In-Reply-To: <87u0e71zpx.fsf@litku.valo.iki.fi> ``` Currently usage of curl was so that netrc was mandatory and passwords in URL weren't allowed. Change netrc to optional to make HTTP basic authentication with username and password in URL also work. Here's an example of such URL: http://foo:bar@www.example.com/auth.git/ Signed-off-by: Kalle Valo --- git-clone.sh | 2 +- git-fetch.sh | 2 +- git-ls-remote.sh | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) applies-to: 8839be40e9401452691ae1b0bf4c86ac616b7bb6 43a79922ab5d3468f0e8614d526b693772d8b1d6 diff --git a/git-clone.sh b/git-clone.sh index c09979a..8af0d5f 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -23,7 +23,7 @@ fi http_fetch () { # $1 = Remote, $2 = Local - curl -nsfL $curl_extra_args "$1" >"$2" + curl -sfL --netrc-optional $curl_extra_args "$1" >"$2" } clone_dumb_http () { diff --git a/git-fetch.sh b/git-fetch.sh index 6586e77..e983cef 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -234,7 +234,7 @@ do $u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg; print "$u"; ' "$remote_name") - head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") && + head=$(curl -sfL --netrc-optional $curl_extra_args "$remote/$remote_name_quoted") && expr "$head" : "$_x40\$" >/dev/null || die "Failed to fetch $remote_name from $remote" echo >&2 Fetching "$remote_name from $remote" using http diff --git a/git-ls-remote.sh b/git-ls-remote.sh index f0f0b07..af8f4b1 100755 --- a/git-ls-remote.sh +++ b/git-ls-remote.sh @@ -42,7 +42,7 @@ http://* | https://* ) if [ -n "$GIT_SSL_NO_VERIFY" ]; then curl_extra_args="-k" fi - curl -nsf $curl_extra_args "$peek_repo/info/refs" || + curl -sf --netrc-optional $curl_extra_args "$peek_repo/info/refs" || echo "failed slurping" ;; --- 0.99.9.GIT ``` ## Junio C Hamano, 2005-11-20 20:21 Subject: Re: [PATCH] Support username and password inside URL Message-ID: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtj3xe72.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <873blriqh0.fsf@litku.valo.iki.fi> ``` Kalle Valo writes: > Currently usage of curl was so that netrc was mandatory and passwords in URL > weren't allowed. Change netrc to optional to make HTTP basic authentication > with username and password in URL also work. HTTP "basic"? Let's at least say "digest" for starters ;-). I am modestly against letting users use auth-embedding URLs, and fairly strongly against encouraging users to do so. It is handy to have weak "authentication" in some situations. I am not ashamed to admit that I've used security-by-obscurity myself, when I sent an email to a friend, saying: Hi, I have some pictures I took during our last trip together, but due to their size I am not attaching them to this e-mail. Please pick them up at: http://members.cox.net/junkio/r0ZIEF/5S54m/ Please drop me a note after picking them up, so that I can clean-up the directory. Auth-embedding URLs are about as secure as the above URL, but it is worse because they may tempt you to reuse the same username password pair for other purposes later. If you are using the password protected URL yourself, I'd imagine having them in your netrc would not be such a big deal, so I suspect your expected usage is not for yourself, but more like giving a temporary, even one-shot, access to others like the above example, and making it more convenient for them (even in that case, if it is not one-shot but for repeated use, I'd imagine it would not be such a big deal to ask them to do appropriate netrc). If that is what is going on here, then IMNSHO it would be better to make it clear that you are doing security-by-obscurity by not using username password pair, which makes you pretend that you are doing _some_ security. ``` ## Krzysztof Halasa, 2005-11-20 20:46 Subject: Re: [PATCH] Support username and password inside URL Message-ID: URL: https://gitlist.dev/e/m3br0fujwc.fsf%40defiant.localdomain In-Reply-To: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > It is handy to have weak "authentication" in some situations. I > am not ashamed to admit that I've used security-by-obscurity > myself, when I sent an email to a friend, saying: > > Hi, I have some pictures I took during our last trip > together, but due to their size I am not attaching them > to this e-mail. Please pick them up at: > > http://members.cox.net/junkio/r0ZIEF/5S54m/ If the above is security by obscurity then any password scheme is, too. After all you're obscuring the password, right? Well, private key and its password can be obscure as well. :-) A common definition says that security by obscurity is using a hidden algorithm and not a shared or private secret. -- Krzysztof Halasa ``` ## Kalle Valo, 2005-11-23 20:56 Subject: Re: [PATCH] Support username and password inside URL Message-ID: <87d5kraxsr.fsf@litku.valo.iki.fi> URL: https://gitlist.dev/e/87d5kraxsr.fsf%40litku.valo.iki.fi In-Reply-To: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > Kalle Valo writes: > >> Currently usage of curl was so that netrc was mandatory and passwords in URL >> weren't allowed. Change netrc to optional to make HTTP basic authentication >> with username and password in URL also work. > > HTTP "basic"? Let's at least say "digest" for starters ;-). Sorry, I didn't understand this. But anyway, I have always used the basic authentication because it has been sufficient for my needs. > I am modestly against letting users use auth-embedding URLs, and > fairly strongly against encouraging users to do so. I didn't even think about security implications when I sent the patch, sorry about that. Now that I think of it, I even remember that some browser removed this feature altogether. Yeah, it was IE: http://support.microsoft.com/kb/834489 And Firefox seems to show a dialog confirmation dialog if I open an URL with username and password. So I have to agree with you, it isn't a good idea to embed the credentials to the URL. > If you are using the password protected URL yourself, I'd > imagine having them in your netrc would not be such a big deal, Yes, I can manage with netrc for now. The only problem is that you can't specify multiple usernames and passwords per host. (Or at least that's how I understood the netrc man page.) If there's a way to do that in git, I would really like to know about that. > so I suspect your expected usage is not for yourself, but more > like giving a temporary, even one-shot, access to others like > the above example, and making it more convenient for them (even > in that case, if it is not one-shot but for repeated use, I'd > imagine it would not be such a big deal to ask them to do > appropriate netrc). Actually I'm going to be only user of the private git repository and it's going to be permanent. I have multiple computers in different locations (servers, workstations, laptops) and I would like to distribute my private files (configuration files, scripts etc.) to all of them using git. The files are not really that secret, but I just don't want to share them with the whole world. That's why I'm using just HTTP authentication and nothing secure. > If that is what is going on here, then IMNSHO it would be better to > make it clear that you are doing security-by-obscurity by not using > username password pair, which makes you pretend that you are doing > _some_ security. I agree with you. I don't consider HTTP authentication secure at all. It can just block search engines and casual readers from accessing the page, nothing more. The problem with randomized URL (like you suggested) is that if some person or a search engine finds the URL somehow, then there's nothing stopping the information leak. HTTP authentication at least stops search engines accessing the page. -- Kalle Valo ``` ## Junio C Hamano, 2005-11-24 22:14 Subject: Re: [PATCH] Support username and password inside URL Message-ID: <7vbr09n16w.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr09n16w.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <87d5kraxsr.fsf@litku.valo.iki.fi> ``` Kalle Valo writes: > Actually I'm going to be only user of the private git repository and > it's going to be permanent. I have multiple computers in different > locations (servers, workstations, laptops) and I would like to > distribute my private files (configuration files, scripts etc.) to all > of them using git. Fair enough. Is "git-push ssh://these.machines/" (or from these.machines "git-fetch ssh://mother.ship/") more trouble than having HTTP server on your mother ship machine? > ... The problem with randomized URL (like you > suggested) is that if some person or a search engine finds the URL > somehow, then there's nothing stopping the information leak. Hmph. I had an impression that the obscure URL scheme like in my example http://members.cox.net/junkio/r0ZIEF/5S54m/ is as robot safe as auth embedding URL. That is, if somebody feeds auth-embedding URL to robots I suspect they can follow it just fine. Of course obscure URL needs to be protected by forbidding dirindex at higher level directories and not posting it to public forum [*1*], for the same reason you have to keep the auth embedding URL from public. [Footnote] *1* I suspect some robots have already tried to harvest what is found at that URL since I posted the message to the list. ``` ## Johannes Schindelin, 2005-11-24 22:24 Subject: Re: [PATCH] Support username and password inside URL Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0511242321500.26651%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vbr09n16w.fsf@assigned-by-dhcp.cox.net> ``` Hi, even if HTTP authentication is not really strong, we could permit at least the username to be specified. The password could come from .netrc. In this manner, it would be possible to use different user names on the same server. I don't have a need for this, though. Ciao, Dscho ``` ## Junio C Hamano, 2005-11-24 23:01 Subject: Re: [PATCH] Support username and password inside URL Message-ID: <7v7jaxmyzt.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v7jaxmyzt.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > even if HTTP authentication is not really strong, we could permit at least > the username to be specified. The password could come from .netrc. In this > manner, it would be possible to use different user names on the same > server. I did not say HTTP authentication in general is not adequate (I did say that at least digest should be used not basic, though). How well does curl work with username but without password in a UR,(e.g. http://joe@host.example.com/frotz/nitfol)? ```