HTTP basic authentication support

HTTP basic authentication support

[Kalle Valo]

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

[PATCH] Support username and password inside URL

[Kalle Valo]

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 <Kalle.Valo@iki.fi>

---

 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

Re: [PATCH] Support username and password inside URL

[Junio C Hamano]

Kalle Valo <Kalle.Valo@iki.fi> 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.

Re: [PATCH] Support username and password inside URL

[Krzysztof Halasa]

Junio C Hamano <junkio@cox.net> 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

Re: [PATCH] Support username and password inside URL

[Kalle Valo]

Junio C Hamano <junkio@cox.net> writes:

> Kalle Valo <Kalle.Valo@iki.fi> 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

Re: [PATCH] Support username and password inside URL

[Junio C Hamano]

Kalle Valo <Kalle.Valo@iki.fi> 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.

Re: [PATCH] Support username and password inside URL

[Johannes Schindelin]

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

Re: [PATCH] Support username and password inside URL

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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)?