{"thread":{"id":"2610","subject":"HTTP basic authentication support","startedAt":"2005-11-20T08:38:02Z","lastAt":"2005-11-24T23:01:42Z","messageCount":8,"participants":["Kalle Valo","Junio C Hamano","Krzysztof Halasa","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12364","messageId":"87u0e71zpx.fsf@litku.valo.iki.fi","threadId":"2610","inReplyTo":null,"subject":"HTTP basic authentication support","fromName":"Kalle Valo","fromEmail":"kalle.valo@iki.fi","sentAt":"2005-11-20T08:38:02Z","receivedAt":"2005-11-20T08:38:02Z","isPatch":false,"sender":{"key":"kalle.valo@iki.fi","avatar":null},"body":"I keep some personal files in a git repository. Now I want to have the\nrepository in an HTTP server so that I can access it everywhere I go.\nSince I don't want to share the repository with the whole world, I\nwould like to use the HTTP basic authentication, just to give a little\nprotection. But it seems that git doesn't support it, yet. Or did I miss\nsomething?\n\nI made a test repository which requires basic authentication. Login is\nfoo and password bar.\n\ngit clone doesn't work:\n\n$ git clone http://foo:bar@www.valo.iki.fi/kalle/tmp/auth.git/ auth  \ndefaulting to local storage area\nCannot get remote repository information.\nPerhaps git-update-server-info needs to be run there?\n$ \n\nBut curl works:\n\n$ curl http://foo:bar@www.valo.iki.fi/kalle/tmp/auth.git/info/refs\n4cb663bd2b92d57c5e1ba0bfa9bf65c2e50ff46a        refs/heads/master\n$ \n\nI'm using git updated an hour ago.\n\n-- \nKalle Valo\n"},{"id":"12366","messageId":"873blriqh0.fsf@litku.valo.iki.fi","threadId":"2610","inReplyTo":"87u0e71zpx.fsf@litku.valo.iki.fi","subject":"[PATCH] Support username and password inside URL","fromName":"Kalle Valo","fromEmail":"kalle.valo@iki.fi","sentAt":"2005-11-20T10:05:47Z","receivedAt":"2005-11-20T10:05:47Z","isPatch":true,"sender":{"key":"kalle.valo@iki.fi","avatar":null},"body":"Currently usage of curl was so that netrc was mandatory and passwords in URL\nweren't allowed. Change netrc to optional to make HTTP basic authentication\nwith username and password in URL also work.\n\nHere's an example of such URL:\n\nhttp://foo:bar@www.example.com/auth.git/\n\nSigned-off-by: Kalle Valo <Kalle.Valo@iki.fi>\n\n---\n\n git-clone.sh     |    2 +-\n git-fetch.sh     |    2 +-\n git-ls-remote.sh |    2 +-\n 3 files changed, 3 insertions(+), 3 deletions(-)\n\napplies-to: 8839be40e9401452691ae1b0bf4c86ac616b7bb6\n43a79922ab5d3468f0e8614d526b693772d8b1d6\ndiff --git a/git-clone.sh b/git-clone.sh\nindex c09979a..8af0d5f 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -23,7 +23,7 @@ fi\n \n http_fetch () {\n \t# $1 = Remote, $2 = Local\n-\tcurl -nsfL $curl_extra_args \"$1\" >\"$2\"\n+\tcurl -sfL --netrc-optional $curl_extra_args \"$1\" >\"$2\"\n }\n \n clone_dumb_http () {\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 6586e77..e983cef 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -234,7 +234,7 @@ do\n \t    $u =~ s{([^-a-zA-Z0-9/.])}{sprintf\"%%%02x\",ord($1)}eg;\n \t    print \"$u\";\n \t' \"$remote_name\")\n-\thead=$(curl -nsfL $curl_extra_args \"$remote/$remote_name_quoted\") &&\n+\thead=$(curl -sfL --netrc-optional $curl_extra_args \"$remote/$remote_name_quoted\") &&\n \texpr \"$head\" : \"$_x40\\$\" >/dev/null ||\n \t\tdie \"Failed to fetch $remote_name from $remote\"\n \techo >&2 Fetching \"$remote_name from $remote\" using http\ndiff --git a/git-ls-remote.sh b/git-ls-remote.sh\nindex f0f0b07..af8f4b1 100755\n--- a/git-ls-remote.sh\n+++ b/git-ls-remote.sh\n@@ -42,7 +42,7 @@ http://* | https://* )\n         if [ -n \"$GIT_SSL_NO_VERIFY\" ]; then\n             curl_extra_args=\"-k\"\n         fi\n-\tcurl -nsf $curl_extra_args \"$peek_repo/info/refs\" ||\n+\tcurl -sf --netrc-optional $curl_extra_args \"$peek_repo/info/refs\" ||\n \t\techo \"failed\tslurping\"\n \t;;\n \n---\n0.99.9.GIT\n"},{"id":"12387","messageId":"7vwtj3xe72.fsf@assigned-by-dhcp.cox.net","threadId":"2610","inReplyTo":"873blriqh0.fsf@litku.valo.iki.fi","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-20T20:21:53Z","receivedAt":"2005-11-20T20:21:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kalle Valo <Kalle.Valo@iki.fi> writes:\n\n> Currently usage of curl was so that netrc was mandatory and passwords in URL\n> weren't allowed. Change netrc to optional to make HTTP basic authentication\n> with username and password in URL also work.\n\nHTTP \"basic\"?  Let's at least say \"digest\" for starters ;-).\n\nI am modestly against letting users use auth-embedding URLs, and\nfairly strongly against encouraging users to do so.\n\nIt is handy to have weak \"authentication\" in some situations.  I\nam not ashamed to admit that I've used security-by-obscurity\nmyself, when I sent an email to a friend, saying:\n\n        Hi, I have some pictures I took during our last trip\n        together, but due to their size I am not attaching them\n        to this e-mail.  Please pick them up at:\n\n\t        http://members.cox.net/junkio/r0ZIEF/5S54m/\n\n        Please drop me a note after picking them up, so that I\n        can clean-up the directory.\n\nAuth-embedding URLs are about as secure as the above URL, but it\nis worse because they may tempt you to reuse the same username\npassword pair for other purposes later.\n\nIf you are using the password protected URL yourself, I'd\nimagine having them in your netrc would not be such a big deal,\nso I suspect your expected usage is not for yourself, but more\nlike giving a temporary, even one-shot, access to others like\nthe above example, and making it more convenient for them (even\nin that case, if it is not one-shot but for repeated use, I'd\nimagine it would not be such a big deal to ask them to do\nappropriate netrc).  If that is what is going on here, then\nIMNSHO it would be better to make it clear that you are doing\nsecurity-by-obscurity by not using username password pair, which\nmakes you pretend that you are doing _some_ security.\n"},{"id":"12389","messageId":"m3br0fujwc.fsf@defiant.localdomain","threadId":"2610","inReplyTo":"7vwtj3xe72.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2005-11-20T20:46:59Z","receivedAt":"2005-11-20T20:46:59Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> It is handy to have weak \"authentication\" in some situations.  I\n> am not ashamed to admit that I've used security-by-obscurity\n> myself, when I sent an email to a friend, saying:\n>\n>         Hi, I have some pictures I took during our last trip\n>         together, but due to their size I am not attaching them\n>         to this e-mail.  Please pick them up at:\n>\n> \t        http://members.cox.net/junkio/r0ZIEF/5S54m/\n\nIf the above is security by obscurity then any password scheme is, too.\nAfter all you're obscuring the password, right?\nWell, private key and its password can be obscure as well. :-)\n\n\nA common definition says that security by obscurity is using a hidden\nalgorithm and not a shared or private secret.\n-- \nKrzysztof Halasa\n"},{"id":"12640","messageId":"87d5kraxsr.fsf@litku.valo.iki.fi","threadId":"2610","inReplyTo":"7vwtj3xe72.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Kalle Valo","fromEmail":"kalle.valo@iki.fi","sentAt":"2005-11-23T20:56:04Z","receivedAt":"2005-11-23T20:56:04Z","isPatch":true,"sender":{"key":"kalle.valo@iki.fi","avatar":null},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Kalle Valo <Kalle.Valo@iki.fi> writes:\n>\n>> Currently usage of curl was so that netrc was mandatory and passwords in URL\n>> weren't allowed. Change netrc to optional to make HTTP basic authentication\n>> with username and password in URL also work.\n>\n> HTTP \"basic\"?  Let's at least say \"digest\" for starters ;-).\n\nSorry, I didn't understand this. But anyway, I have always used the\nbasic authentication because it has been sufficient for my needs.\n\n> I am modestly against letting users use auth-embedding URLs, and\n> fairly strongly against encouraging users to do so.\n\nI didn't even think about security implications when I sent the patch,\nsorry about that. Now that I think of it, I even remember that some\nbrowser removed this feature altogether. Yeah, it was IE:\n\nhttp://support.microsoft.com/kb/834489\n\nAnd Firefox seems to show a dialog confirmation dialog if I open an\nURL with username and password. So I have to agree with you, it isn't\na good idea to embed the credentials to the URL.\n\n> If you are using the password protected URL yourself, I'd\n> imagine having them in your netrc would not be such a big deal,\n\nYes, I can manage with netrc for now. The only problem is that you\ncan't specify multiple usernames and passwords per host. (Or at least\nthat's how I understood the netrc man page.) If there's a way to do\nthat in git, I would really like to know about that.\n\n> so I suspect your expected usage is not for yourself, but more\n> like giving a temporary, even one-shot, access to others like\n> the above example, and making it more convenient for them (even\n> in that case, if it is not one-shot but for repeated use, I'd\n> imagine it would not be such a big deal to ask them to do\n> appropriate netrc).\n\nActually I'm going to be only user of the private git repository and\nit's going to be permanent. I have multiple computers in different\nlocations (servers, workstations, laptops) and I would like to\ndistribute my private files (configuration files, scripts etc.) to all\nof them using git. The files are not really that secret, but I just\ndon't want to share them with the whole world. That's why I'm using\njust HTTP authentication and nothing secure.\n\n> If that is what is going on here, then IMNSHO it would be better to\n> make it clear that you are doing security-by-obscurity by not using\n> username password pair, which makes you pretend that you are doing\n> _some_ security.\n\nI agree with you. I don't consider HTTP authentication secure at all.\nIt can just block search engines and casual readers from accessing the\npage, nothing more. The problem with randomized URL (like you\nsuggested) is that if some person or a search engine finds the URL\nsomehow, then there's nothing stopping the information leak. HTTP\nauthentication at least stops search engines accessing the page.\n\n-- \nKalle Valo\n"},{"id":"12708","messageId":"7vbr09n16w.fsf@assigned-by-dhcp.cox.net","threadId":"2610","inReplyTo":"87d5kraxsr.fsf@litku.valo.iki.fi","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-24T22:14:15Z","receivedAt":"2005-11-24T22:14:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kalle Valo <Kalle.Valo@iki.fi> writes:\n\n> Actually I'm going to be only user of the private git repository and\n> it's going to be permanent. I have multiple computers in different\n> locations (servers, workstations, laptops) and I would like to\n> distribute my private files (configuration files, scripts etc.) to all\n> of them using git.\n\nFair enough.  Is \"git-push ssh://these.machines/\" (or from\nthese.machines \"git-fetch ssh://mother.ship/\") more trouble than\nhaving HTTP server on your mother ship machine?\n\n> ... The problem with randomized URL (like you\n> suggested) is that if some person or a search engine finds the URL\n> somehow, then there's nothing stopping the information leak.\n\nHmph.  I had an impression that the obscure URL scheme like in\nmy example http://members.cox.net/junkio/r0ZIEF/5S54m/ is as\nrobot safe as auth embedding URL.  That is, if somebody feeds\nauth-embedding URL to robots I suspect they can follow it just\nfine.  Of course obscure URL needs to be protected by forbidding\ndirindex at higher level directories and not posting it to\npublic forum [*1*], for the same reason you have to keep the\nauth embedding URL from public.\n\n[Footnote]\n\n*1* I suspect some robots have already tried to harvest what is\nfound at that URL since I posted the message to the list.\n"},{"id":"12709","messageId":"Pine.LNX.4.63.0511242321500.26651@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2610","inReplyTo":"7vbr09n16w.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-24T22:24:06Z","receivedAt":"2005-11-24T22:24:06Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\neven if HTTP authentication is not really strong, we could permit at least \nthe username to be specified. The password could come from .netrc. In this \nmanner, it would be possible to use different user names on the same \nserver.\n\nI don't have a need for this, though.\n\nCiao,\nDscho\n"},{"id":"12710","messageId":"7v7jaxmyzt.fsf@assigned-by-dhcp.cox.net","threadId":"2610","inReplyTo":"Pine.LNX.4.63.0511242321500.26651@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Support username and password inside URL","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-24T23:01:42Z","receivedAt":"2005-11-24T23:01:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> even if HTTP authentication is not really strong, we could permit at least \n> the username to be specified. The password could come from .netrc. In this \n> manner, it would be possible to use different user names on the same \n> server.\n\nI did not say HTTP authentication in general is not adequate (I\ndid say that at least digest should be used not basic, though).\n\nHow well does curl work with username but without password in a\nUR,(e.g. http://joe@host.example.com/frotz/nitfol)?\n"}]}