http authentication via prompts
PATCH 1/1 http authentication via prompts
Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
With the old .netrc working, this patch provides backwards compatibility while adding a more secure option for users whose http password may be sensitive (such as if its a domain controller password) and do not wish to have it on the filesystem.
--- Documentation/config.txt | 7 +++ Documentation/howto/setup-git-server-over-http.txt | 38 ++++++++++++++++-- http.c | 41 ++++++++++++++++++- http.h | 2 + 4 files changed, 81 insertions(+), 7 deletions(-)
Documentation/config.txt +7 -0
@@ -920,6 +920,13 @@ help.autocorrect:: value is 0 - the command will be just shown but not executed. This is the default. +http.username, http.password: + The username and password for http authentication. http.username is + required, http.password is optional. If supplied, the .netrc file will + be ignored. If a password is not supplied, git will prompt for it. + Be careful when configuring a password as it will be stored in plain text + on the filesystem. + http.proxy:: Override the HTTP proxy, normally configured using the 'http_proxy' environment variable (see linkgit:curl[1]). This can be overridden
Documentation/howto/setup-git-server-over-http.txt +34 -4
@@ -189,8 +189,19 @@ Make sure that you have HTTP support, i.e. your git was built with libcurl (version more recent than 7.10). The command 'git http-push' with no argument should display a usage message. -Then, add the following to your $HOME/.netrc (you can do without, but will be -asked to input your password a _lot_ of times): +There are 2 ways to authenticate with git http, netrc and via the git config. +The netrc option requires that you put the username and password for the connection +in $HOME/.netrc. The configuration method allows you to specify a username and +optionally a password. If the password is not supplied then git will prompt you +for the password. The downside to the netrc method is that you must have your +username and password in plaintext on the filesystem, albeit in a protected file. +If the username/password combo is a sensitive one, you may wish to use the +git config method. The downside of the config method is that you will be prompted +for your password every time you push or pull to the remote repository. + +Using netrc: + +Using your favourite ext editor, add the following to your $HOME/.netrc: machine <servername> login <username>
@@ -204,7 +215,7 @@ instead of the server name. To check whether all is OK, do: - curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD + curl --netrc --location -v http://<servername>/my-new-repo.git/HEAD ...this should give something like 'ref: refs/heads/master', which is the content of the file HEAD on the server.
@@ -213,12 +224,31 @@ Now, add the remote in your existing repository which contains the project you want to export: $ git-config remote.upload.url \ - http://<username>@<servername>/my-new-repo.git/ + http://<servername>/my-new-repo.git/ It is important to put the last '/'; Without it, the server will send a redirect which git-http-push does not (yet) understand, and git-http-push will repeat the request infinitely. +Using git config: + +curl --user <username>:<password> --location -v http://<servername>/my-new-repo.git/HEAD + +...this should give something like 'ref: refs/heads/master', which is +the content of the file HEAD on the server. + +Now, add the remote in your existing repository which contains the project +you want to export: + + $ git-config remote.upload.url \ + http://<servername>/my-new-repo.git/ + +Also, add in your username with: + $ git-config http.username <username> + +And optionally your password (you will be prompted for it if you do not): + $ git-config http.password <password> + Step 4: make the initial push -----------------------------
http.c +38 -3
64 lines not on this page · raw message
http.h +2 -0
@@ -5,6 +5,8 @@#include <curl/curl.h> #include <curl/easy.h> +#include <termios.h> +#include <stdio.h> #include "strbuf.h" #include "remote.h"
Signature · 1 line
1.6.1.2
Quoted 3 lines · Mike Gaffney
Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
With the old .netrc working, this patch provides backwards compatibility while adding a more secure option for users whose http password may be sensitive (such as if its a domain controller password) and do not wish to have it on the filesystem.
Please wrap lines to readable length, such as under 72 cols.
Quoted 6 lines
Documentation/config.txt +0
-0@@ -920,6 +920,13 @@ help.autocorrect:: value is 0 - the command will be just shown but not executed.
Documentation/config.txt help.autocorrect:: · line 930
Quoted 10 lines
Documentation/config.txt +7
-0This is the default. +http.username, http.password: + The username and password for http authentication. http.username is + required, http.password is optional. If supplied, the .netrc file will + be ignored. If a password is not supplied, git will prompt for it. + Be careful when configuring a password as it will be stored in plain text + on the filesystem. + http.proxy::
List item ends with double colons; two headline items that are described with the same description are listed each on its own line. I.e.
http.username::
http.password::
The username and ...
Quoted 9 lines
Documentation/howto/setup-git-server-over-http.txt +0
-1@@ -189,8 +189,19 @@ Make sure that you have HTTP support, i.e. your git was built with libcurl (version more recent than 7.10). The command 'git http-push' with no argument should display a usage message. -Then, add the following to your $HOME/.netrc (you can do without, but will be
Documentation/howto/setup-git-server-over-http.txt Make sure that you have HTTP support, i.e. your git was built with · line 200
Quoted 10 lines
Documentation/howto/setup-git-server-over-http.txt +9
-1-asked to input your password a _lot_ of times): +There are 2 ways to authenticate with git http, netrc and via the git config. +The netrc option requires that you put the username and password for the connection +in $HOME/.netrc. The configuration method allows you to specify a username and +optionally a password. If the password is not supplied then git will prompt you +for the password. The downside to the netrc method is that you must have your +username and password in plaintext on the filesystem, albeit in a protected file. +If the username/password combo is a sensitive one, you may wish to use the +git config method. The downside of the config method is that you will be prompted +for your password every time you push or pull to the remote repository.
The contents look readable, but each line is a bit too long.
Documentation/howto/setup-git-server-over-http.txt instead of the server name. · line 218
Quoted 6 lines
Documentation/howto/setup-git-server-over-http.txt +1
-1@@ -204,7 +215,7 @@ instead of the server name. To check whether all is OK, do: - curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD + curl --netrc --location -v http://<servername>/my-new-repo.git/HEAD
Why?
Documentation/howto/setup-git-server-over-http.txt Now, add the remote in your existing repository which contains the project · line 227
Quoted 6 lines
Documentation/howto/setup-git-server-over-http.txt +1
-1@@ -213,12 +224,31 @@ Now, add the remote in your existing repository which contains the project you want to export: $ git-config remote.upload.url \ - http://<username>@<servername>/my-new-repo.git/ + http://<servername>/my-new-repo.git/
Why?
Documentation/howto/setup-git-server-over-http.txt Now, add the remote in your existing repository which contains the project · line 233
Quoted 1 line
Documentation/howto/setup-git-server-over-http.txt +1
-0+Using git config:
The bulk of text before this does not have a subtitle like this. Perhaps you would want to add one? The presense of this subtitle makes it clear that you are going to talk about _another_ way, but for first time readers it is unclear how that other way is different and what its advantages are.
Perhaps drop this subtitle, and instead give one short paragraph, e.g.
Instead of storing your password in plaintext $HOME/.netrc file, you can store only the username in the configuration file and have the program prompt for a password. Here is how.
Alternatively keep the subtitle and explain what the subsection is about in a similar way.
But I think this section raises a bigger usability and user perception issue.
When "http://user@host/rest" URL is given to your "git push/fetch", without .netrc nor http.username configuration, we allow the curl library to prompt for a password, and because we do not reuse the password (and reinstantiate the curl handle), we end up asking the user million times.
But from the end user's point of view, that's all implementation detail. It does not explain why "http://user@host/rest" acts in a silly way, and "http://host/rest" with http.username configuration doesn't.
Perhaps you instead inspect the URL and see if you have the "user" part (without password), and then:
(1) transform the URL to http://host/rest" before giving it to libcurl; and
(2) use your CURLOPT_USERPWD logic with your own getpass() call in
init_curl_http_auth()?
That way you do not have (even though you could) to introduce a new configuration, nor have a new section in the documentation. It will be a straightforward fix of the "will be asked ... a lot of times" bug you removed from the documentation, no?
http.c static long curl_low_speed_time = -1; · line 31
Quoted 11 lines
http.c +3
-0@@ -26,6 +26,9 @@ static long curl_low_speed_time = -1;static int curl_ftp_no_epsv =0 ;static const char *curl_http_proxy =NULL ; +static const char *curl_http_username =NULL ; +static const char *curl_http_password =NULL ; +
Please do not introduce new initializations of static variables to 0 or NULL. As a clean-up, before your patch, you can send in a patch to fix existing such initializations.
Quoted 4 lines
http.c +4
-0+static void init_curl_http_auth (CURL * result){ +#if LIBCURL_VERSION_NUM >=0x070907 +struct strbuf userpass; +strbuf_init (&userpass,0 );
http.c static int http_options(const char *var, const char *value, void *cb) · line 191
Quoted 10 lines
http.c +10
-0+if (curl_http_username !=NULL ) { +strbuf_addstr (&userpass, curl_http_username); +strbuf_addstr (&userpass,":" ); +if (curl_http_password !=NULL ) { +strbuf_addstr (&userpass, curl_http_password); + }else { +strbuf_addstr (&userpass,getpass ("Password: " )); + } +curl_easy_setopt (result,CURLOPT_USERPWD , userpass.buf); +curl_easy_setopt (result,CURLOPT_NETRC ,CURL_NETRC_IGNORED );
Why NETRC_IGNORED?
On CURLOPT_NETRC, http://curl.haxx.se/libcurl/c/curl_easy_setopt.html says
libcurl uses a user name (and supplied or prompted password) supplied with CURLOPT_USERPWD in preference to any of the options controlled by this parameter.
Does it not work as advertised?
In short, I think what you did in init_curl_http_auth() makes a lot of sense except for the NETRC_IGNORED bit, but:
(1) I think http.password configuration has the exact same "plaintext password in a read-protected file" issue as .netrc; it is unnecessary.
(2) http.username is used by your patch primarily as a way to trigger the new logic to call getpass() and use CURLOPT_USERPWD. It would be a lot nicer to inspect the URL to notice that there is a username part in it and triggering the same codepath. That would be a genuine improvement (and you can even claim it is a bugfix). And if that works, the new configuration variable does not add much value (except that different people involved in the same project can use the same URL but their own (username, password) pair to access it.
Hi,
Disclaimer: if you are offended by constructive criticism, or likely to answer with insults to the comments I offer, please stop reading this mail now (and please do not answer my mail, either). :-)
Still with me? Good. Nice to meet you.
Just for the record: responding to a patch is my strongest way of saying that I appreciate your work.
Quoted 9 lines · Mike Gaffney
Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
From the subject, I would have expected a way to type in the password
instead of storing it. (Think getpass()... which would pose problems with Windows support, of course.)
FWIW by having it in .git/config (which is most likely more world-readable than $HOME/.netrc ever will be) does not provide any security over .netrc.
And I doubt that http.username is a good choice: what if you have multiple
http:// URLs with different usernames/passwords? So would it not make more sense to make this remote.<name>.user and ...password?
Ciao,
Dscho
My thought was that if you had a password you didn't care about you could put it in the config. It does ask you for a password with getpass, It compiles under cygwin, I havent tried it under windows. However the man page for getpass shows the source so coding up getpass directly isn't a big deal.
Junio, I'm new to this patch game and using Thunderbird. What's the best way to wrap the patch?
-Mike
Quoted 34 lines · Johannes Schindelin
Hi,
Disclaimer: if you are offended by constructive criticism, or likely to answer with insults to the comments I offer, please stop reading this mail now (and please do not answer my mail, either). :-)
Still with me? Good. Nice to meet you.
Just for the record: responding to a patch is my strongest way of saying that I appreciate your work.
Quoted 7 lines · Mike Gaffney
Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
From the subject, I would have expected a way to type in the password instead of storing it. (Think
getpass()... which would pose problems with Windows support, of course.)FWIW by having it in .git/config (which is most likely more world-readable than $HOME/.netrc ever will be) does not provide any security over .netrc.
And I doubt that http.username is a good choice: what if you have multiple
http:// URLs with different usernames/passwords? So would it not make more sense to make this remote.<name>.user and ...password?Ciao,
Dscho
Signature · 1 line
-Mike Gaffney (http://rdocul.us)
Quoted 3 lines · Mike Gaffney
My thought was that if you had a password you didn't care about you could put it in the config. It does ask you for a password with getpass, It compiles under cygwin, I havent tried it under windows.
I think part of the confusion is that your patch does two things, which means it is probably more sensible as two separate patches:
1. support http.username and http.password in the git config instead of the .netrc
2. support getpass() if http.password (or .netrc password) is not available
-Peff
On Thu, Mar 05, 2009 at 09:15:29AM -0600, Mike Gaffney wrote:
Hi.
Quoted 2 lines
Junio, I'm new to this patch game and using Thunderbird. What's the best way to wrap the patch?
I'm not Junio, but I'll give answering a shot anyway. ;-)
See Documentation/SubmittingPatches, line 374-456.
Signature · 1 line
Fredrik Skolmli