All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH][v2] http authentication via prompts (with correct line lengths)
@ 2009-03-10  0:08 Mike Gaffney
  2009-03-10  0:37 ` Junio C Hamano
  0 siblings, 1 reply; 25+ messages in thread
From: Mike Gaffney @ 2009-03-10  0:08 UTC (permalink / raw)
  To: git

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.

Signed-off-by: Mike Gaffney <mike@uberu.com>
---
 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(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index f5152c5..821bf48 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -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
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index 622ee5c..462a9d4 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -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
 -----------------------------
diff --git a/http.c b/http.c
index ee58799..348b9fb 100644
--- a/http.c
+++ b/http.c
@@ -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;
+
 static struct curl_slist *pragma_header;
 
 static struct active_request_slot *active_queue_head = NULL;
@@ -153,11 +156,45 @@ static int http_options(const char *var, const char *value, void *cb)
 			return git_config_string(&curl_http_proxy, var, value);
 		return 0;
 	}
+	if (!strcmp("http.username", var)) {
+		if (curl_http_username == NULL)
+		{
+			return git_config_string(&curl_http_username, var, value);
+		}
+		return 0;
+	}
+	if (!strcmp("http.password", var)) {
+		if (curl_http_password == NULL)
+		{
+			return git_config_string(&curl_http_password, var, value);
+		}
+		return 0;
+	}
 
 	/* Fall back on the default ones */
 	return git_default_config(var, value, cb);
 }
 
+static void init_curl_http_auth(CURL* result){
+#if LIBCURL_VERSION_NUM >= 0x070907
+        struct strbuf userpass;
+        strbuf_init(&userpass, 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);
+        } else {
+		curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
+        }
+#endif
+}
+
 static CURL* get_curl_handle(void)
 {
 	CURL* result = curl_easy_init();
@@ -172,9 +209,7 @@ static CURL* get_curl_handle(void)
 		curl_easy_setopt(result, CURLOPT_SSL_VERIFYHOST, 2);
 	}
 
-#if LIBCURL_VERSION_NUM >= 0x070907
-	curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
-#endif
+        init_curl_http_auth(result);
 
 	if (ssl_cert != NULL)
 		curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
diff --git a/http.h b/http.h
index 905b462..71320d1 100644
--- a/http.h
+++ b/http.h
@@ -5,6 +5,8 @@
 
 #include <curl/curl.h>
 #include <curl/easy.h>
+#include <termios.h>
+#include <stdio.h>
 
 #include "strbuf.h"
 #include "remote.h"
-- 
1.6.1.2

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  0:08 [PATCH][v2] http authentication via prompts (with correct line lengths) Mike Gaffney
@ 2009-03-10  0:37 ` Junio C Hamano
  2009-03-10  0:45   ` Johannes Schindelin
  2009-03-10  4:46   ` Mike Gaffney
  0 siblings, 2 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-10  0:37 UTC (permalink / raw)
  To: Mike Gaffney; +Cc: git

It appears that none of the issues I raised in my response to your earlier
round was addressed in this patch, except for the line rewrapping of the
proposed commit log message.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  0:37 ` Junio C Hamano
@ 2009-03-10  0:45   ` Johannes Schindelin
  2009-03-10  3:25     ` Mike Gaffney
  2009-03-10  4:46   ` Mike Gaffney
  1 sibling, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2009-03-10  0:45 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Gaffney, git

Hi,

On Mon, 9 Mar 2009, Junio C Hamano wrote:

> It appears that none of the issues I raised in my response to your 
> earlier round was addressed in this patch, except for the line 
> rewrapping of the proposed commit log message.

AFAICT my concerns were not addressed either: misleading subject unless 
the patch is split into two, remote specific config variable instead of 
global one, security issues.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  0:45   ` Johannes Schindelin
@ 2009-03-10  3:25     ` Mike Gaffney
  2009-03-10 10:43       ` Johannes Schindelin
  0 siblings, 1 reply; 25+ messages in thread
From: Mike Gaffney @ 2009-03-10  3:25 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Junio C Hamano, git

I guess it makes sense to split the config out into two patches. I wanted both to help with automated builds, and as it's a read only account I wasn't worried about someone reading the password. I'm not very impressed with the permissions on the .netrc file actually providing security so I can see not allowing the password in the config either. In my system at work, we have shared machines but all developers have root access, so file permissions don't really secure anything for us. It's also why we can't really use keys (there is no way to enforce that a key is secured afaik).

I wanted to do a remote specific config as well but a global works well in many environments where your push repo is under http as you don't keep having to configure it. I also couldn't see a good way to do a remote specific config without changing the remote struct (which seemd like putting specific in a general). I would love some advice on this and where to put it.

I can see your security points but I would argue that if that's what we are worried about then we should not allow the netrc file at all. I added notes in the config documentation about this. I'm open to discussion on this point.

Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 9 Mar 2009, Junio C Hamano wrote:
> 
>> It appears that none of the issues I raised in my response to your 
>> earlier round was addressed in this patch, except for the line 
>> rewrapping of the proposed commit log message.
> 
> AFAICT my concerns were not addressed either: misleading subject unless 
> the patch is split into two, remote specific config variable instead of 
> global one, security issues.
> 
> Ciao,
> Dscho
> 

-- 
-Mike Gaffney (http://rdocul.us)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  0:37 ` Junio C Hamano
  2009-03-10  0:45   ` Johannes Schindelin
@ 2009-03-10  4:46   ` Mike Gaffney
  2009-03-10  6:34     ` Junio C Hamano
  1 sibling, 1 reply; 25+ messages in thread
From: Mike Gaffney @ 2009-03-10  4:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

Junio,
	Just spent about 30 minutes replying to your points until the last one
made most moot. I agree that putting the info into the url will fix the bug, 
which I have never seen (see #3 below), and make the howto easier to read. So a 
few things I wanted to discuss or ask for help on:

1) Note that I'm not a C guy so:

Junio wrote:
>> +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.

I'm not sure what you mean here. Should I just declare them as:
static const char *curl_http_password; ?

Also do you mean that during after the patch phase they get changed to:
static const char *curl_http_password = NULL; ?

Or do you mean that I can send in a patch to fix other static variables
(not mine) which are being initialized to NULL?

2) Being that I'm not a big C guy, I'm not sure the best way to go about 
parsing the username out of the URL to pull it into a variable to pass
to CURLOPT_USERPASS. Any advice from the community would be greatly
appreciated.

3) From my experience with curl, many of the options do
not work the same across versions or platforms. For example, the new
CURLOPT_USERNAME/PASSWORD options worked fine in 7.19.4 on cygwin but not
on FC9, which is why I used the older USERPWD. Also, my curl never prompted
me for the password when I supplied a username in the URL which is what 
prompted me to do this patch in the first place. As such, I think it is
better to pull the username & password prompting logic into git make this 
stable and fix the bug. 

4) I'm not really impressed that file permissions actually make the .netrc
file a secure option. However, it's already in there and would break
backwards compatibility to take it out. I also realize that there is a need
for automated builds to be able to pull the source. So I would like to add a nice 
warning section to the http docs explaining the repercussions of using it.

Thanks for the help,
	Mike

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  4:46   ` Mike Gaffney
@ 2009-03-10  6:34     ` Junio C Hamano
  2009-03-10  8:08       ` Daniel Stenberg
  2009-03-12  8:53       ` Mike Ralphson
  0 siblings, 2 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-10  6:34 UTC (permalink / raw)
  To: Mike Gaffney; +Cc: git

Mike Gaffney <mr.gaffo@gmail.com> writes:

>>> +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.
> ...
> Or do you mean that I can send in a patch to fix other static variables
> (not mine) which are being initialized to NULL?

Yeah, a preparatory patch to clean things up, like the one I sent out
earlier this evening, was what I meant.

> 2) Being that I'm not a big C guy, I'm not sure the best way to go about 
> parsing the username out of the URL to pull it into a variable to pass
> to CURLOPT_USERPASS. Any advice from the community would be greatly
> appreciated.

I am sort of a C guy, but I am by no means a libcurl person.  A quick and
dirty patch is attached, which is partly based on yours, but is stripped
of version dependency and also I suspect it handles only the http-walker
side.  It is on top of the two clean-up patch I sent this evening.

It hasn't seen any test, but I just ran this once:

    $ git clone http://junio@my.private.machine/test-repo.git/

from a repository that requires authentication but I have no .netrc and no
http.password configuration; I was asked for the password once, of course.

> 3) From my experience with curl, many of the options do
> not work the same across versions or platforms. For example, the new
> CURLOPT_USERNAME/PASSWORD options worked fine in 7.19.4 on cygwin but not
> on FC9, which is why I used the older USERPWD. Also, my curl never prompted
> me for the password when I supplied a username in the URL which is what 
> prompted me to do this patch in the first place. As such, I think it is
> better to pull the username & password prompting logic into git make this 
> stable and fix the bug. 

Heh, 7.19.4 was only released on a few days ago if I am reading its
download page correctly.

The version of libcurl on my box is 7.18.something, and it does not seem
to ask for password when the URL has only username but not colon-password.
I also expected it to ask for password when $HOME/.netrc has login but not
password for a given machine, but that does not seem to happen either.
Perhaps the version is too old.

> 4) I'm not really impressed that file permissions actually make the .netrc
> file a secure option. However, it's already in there and would break
> backwards compatibility to take it out. I also realize that there is a need
> for automated builds to be able to pull the source. So I would like to add a nice 
> warning section to the http docs explaining the repercussions of using it.

I agree with the first two sentences and am not happy with http.password
because of it.


---
 http.c |   60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/http.c b/http.c
index f4f0bf6..3d5caa6 100644
--- a/http.c
+++ b/http.c
@@ -25,6 +25,7 @@ static long curl_low_speed_limit = -1;
 static long curl_low_speed_time = -1;
 static int curl_ftp_no_epsv;
 static const char *curl_http_proxy;
+static char *user_name, *user_pass;
 
 static struct curl_slist *pragma_header;
 
@@ -135,6 +136,20 @@ static int http_options(const char *var, const char *value, void *cb)
 	return git_default_config(var, value, cb);
 }
 
+static void init_curl_http_auth(CURL *result)
+{
+	if (!user_name)
+		curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
+	else {
+		struct strbuf up = STRBUF_INIT;
+		if (!user_pass)
+			user_pass = xstrdup(getpass("Password: "));
+		strbuf_addf(&up, "%s:%s", user_name, user_pass);
+		curl_easy_setopt(result, CURLOPT_USERPWD,
+				 strbuf_detach(&up, NULL));
+	}
+}
+
 static CURL *get_curl_handle(void)
 {
 	CURL *result = curl_easy_init();
@@ -153,6 +168,8 @@ static CURL *get_curl_handle(void)
 	curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
 #endif
 
+	init_curl_http_auth(result);
+
 	if (ssl_cert != NULL)
 		curl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);
 #if LIBCURL_VERSION_NUM >= 0x070902
@@ -190,6 +207,46 @@ static CURL *get_curl_handle(void)
 	return result;
 }
 
+static void http_auth_init(const char *url)
+{
+	char *at, *colon, *cp, *slash;
+	int len;
+
+	cp = strstr(url, "://");
+	if (!cp)
+		return;
+
+	/*
+	 * Ok, the URL looks like "proto://something".  Which one?
+	 * "proto://<user>:<pass>@<host>/...",
+	 * "proto://<user>@<host>/...", or just
+	 * "proto://<host>/..."?
+	 */
+	cp += 3;
+	at = strchr(cp, '@');
+	colon = strchr(cp, ':');
+	slash = strchrnul(cp, '/');
+	if (!at || slash <= at)
+		return; /* No credentials */
+	if (!colon || at <= colon) {
+		/* Only username */
+		len = at - cp;
+		user_name = xmalloc(len + 1);
+		memcpy(user_name, cp, len);
+		user_name[len] = '\0';
+		user_pass = NULL;
+	} else {
+		len = colon - cp;
+		user_name = xmalloc(len + 1);
+		memcpy(user_name, cp, len);
+		user_name[len] = '\0';
+		len = at - (colon + 1);
+		user_pass = xmalloc(len + 1);
+		memcpy(user_pass, colon + 1, len);
+		user_pass[len] = '\0';
+	}
+}
+
 void http_init(struct remote *remote)
 {
 	char *low_speed_limit;
@@ -252,6 +309,9 @@ void http_init(struct remote *remote)
 	if (getenv("GIT_CURL_FTP_NO_EPSV"))
 		curl_ftp_no_epsv = 1;
 
+	if (remote && remote->url && remote->url[0])
+		http_auth_init(remote->url[0]);
+
 #ifndef NO_CURL_EASY_DUPHANDLE
 	curl_default = get_curl_handle();
 #endif

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  6:34     ` Junio C Hamano
@ 2009-03-10  8:08       ` Daniel Stenberg
  2009-03-10  8:35         ` Junio C Hamano
  2009-03-12  8:53       ` Mike Ralphson
  1 sibling, 1 reply; 25+ messages in thread
From: Daniel Stenberg @ 2009-03-10  8:08 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Gaffney, git

On Mon, 9 Mar 2009, Junio C Hamano wrote:

> The version of libcurl on my box is 7.18.something, and it does not seem to 
> ask for password when the URL has only username but not colon-password. I 
> also expected it to ask for password when $HOME/.netrc has login but not 
> password for a given machine, but that does not seem to happen either. 
> Perhaps the version is too old.

No, that's entirely expected. libcurl has no "prompt the user if no password 
was given" logic but instead delegates that work to the application.

There was once functionality for this (removed in October 2003) but it was 
broken and violated internal guidelines so we cut out and threw that code 
away.

More recently there have been people interested in re-implementing this "the 
right way" but so far it hasn't been made and thus the application is left to 
perform this task.

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  8:08       ` Daniel Stenberg
@ 2009-03-10  8:35         ` Junio C Hamano
  0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-10  8:35 UTC (permalink / raw)
  To: Daniel Stenberg; +Cc: Mike Gaffney, git

Daniel Stenberg <daniel@haxx.se> writes:

> On Mon, 9 Mar 2009, Junio C Hamano wrote:
>
>> The version of libcurl on my box is 7.18.something, and it does not
>> seem to ask for password when the URL has only username but not
>> colon-password. I also expected it to ask for password when
>> $HOME/.netrc has login but not password for a given machine, but
>> that does not seem to happen either. Perhaps the version is too old.
>
> No, that's entirely expected. libcurl has no "prompt the user if no
> password was given" logic but instead delegates that work to the
> application.
>
> There was once functionality for this (removed in October 2003) but it
> was broken and violated internal guidelines so we cut out and threw
> that code away.
>
> More recently there have been people interested in re-implementing
> this "the right way" but so far it hasn't been made and thus the
> application is left to perform this task.

It's always nice to find _the_ area expert around ;-)

I somehow misread the description on CURLOPT_NETRC that appears in
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html:

	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.

especially the "or prompted password" part to mean that unless supplied to
the library by the caller the library would prompt the user and obtain the
password.

Thanks for clarification.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10  3:25     ` Mike Gaffney
@ 2009-03-10 10:43       ` Johannes Schindelin
  2009-03-10 15:33         ` Mike Gaffney
  0 siblings, 1 reply; 25+ messages in thread
From: Johannes Schindelin @ 2009-03-10 10:43 UTC (permalink / raw)
  To: Mike Gaffney; +Cc: Junio C Hamano, git

Hi,

On Mon, 9 Mar 2009, Mike Gaffney wrote:

> I guess it makes sense to split the config out into two patches.

I guess, too, because it has been asked for.  I guess that since nobody 
contradicted that wish, it would make sense, I guess.

> I wanted both to help with automated builds, and as it's a read only 
> account I wasn't worried about someone reading the password. I'm not 
> very impressed with the permissions on the .netrc file actually 
> providing security so I can see not allowing the password in the config 
> either.

If Git were written for you, for that very specific setup, then yes, I can 
see that one does not need to care about storing passwords in plaintext 
files _there_.

However, in addition to you, Git was written for some others, too.

And $HOME/.netrc is a well established paradigm, many programs check the 
permissions and flatly refuse to run with a big red warning if the 
permissions are not set restrictively.  So there is definitely a big, 
huge, vast difference between storing passwords in $HOME/.netrc and 
storing them in .git/config.

> In my system at work, we have shared machines but all developers have 
> root access, so file permissions don't really secure anything for us. 
> It's also why we can't really use keys (there is no way to enforce that 
> a key is secured afaik).

Again, happily the Git team decided that in addition to you, we want to 
support other users.  For example us.

And we _do_ work on computers where only trustworthy people have root 
access.

> I wanted to do a remote specific config as well but a global works well 
> in many environments where your push repo is under http as you don't 
> keep having to configure it.

IMHO in this case, "works well" does not mean the same as "makes sense" at 
all.

Again, Git was written for other people, too.

It should not be necessary to say more, but here I go: on two projects I 
have to push to multiple HTTP servers, and I do have different passwords 
there.

However, I am pretty convinced that it is a good idea to have the 
passwords in $HOME/.netrc where they belong instead of in a config where 
it is all too easy to fsck up the permissions.

BTW that is another reason (in addition to it just being good style, 
separating different issues into different patches) why I want you to 
split the patch: to reject something insecure (storing passwords in 
config) and to accept the secure part (reading passwords interactively 
from the console).

> I also couldn't see a good way to do a remote specific config without 
> changing the remote struct (which seemd like putting specific in a 
> general). I would love some advice on this and where to put it.

Umm.  Into the remote struct?

> I can see your security points but I would argue that if that's what we 
> are worried about then we should not allow the netrc file at all.

See above.

> I added notes in the config documentation about this. I'm open to 
> discussion on this point.

Oh, so you mean you will address my concerns?  That's good, as I am 
looking forward to your answers to them.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-10 10:43       ` Johannes Schindelin
@ 2009-03-10 15:33         ` Mike Gaffney
  0 siblings, 0 replies; 25+ messages in thread
From: Mike Gaffney @ 2009-03-10 15:33 UTC (permalink / raw)
  To: Johannes Schindelin, git

Johannes,
	Your points make sense, thank you for clarifying, it helps 
me understand what the underlying concerns are. The attitude doesn't really 
help.
	Does Junio's counter solution where git would prompt for the
password if the username contained a url solve your concerns with unsecure
config variables? The patch would be just a bugfix to current functionality.
	Also, libcurl does not warn you that you have an insecure netrc file.
Just tried it with 7.19.4 on cygwin and FC9.

Thanks for the feedback,
	Mike

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-10  6:34     ` Junio C Hamano
  2009-03-10  8:08       ` Daniel Stenberg
@ 2009-03-12  8:53       ` Mike Ralphson
  2009-03-12  8:59         ` Daniel Stenberg
  2009-03-13  5:53         ` Junio C Hamano
  1 sibling, 2 replies; 25+ messages in thread
From: Mike Ralphson @ 2009-03-12  8:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Gaffney, git

2009/3/10 Junio C Hamano <gitster@pobox.com>:
> diff --git a/http.c b/http.c
> index f4f0bf6..3d5caa6 100644
> --- a/http.c
> +++ b/http.c
> @@ -25,6 +25,7 @@ static long curl_low_speed_limit = -1;
>  static long curl_low_speed_time = -1;
>  static int curl_ftp_no_epsv;
>  static const char *curl_http_proxy;
> +static char *user_name, *user_pass;
>
>  static struct curl_slist *pragma_header;
>
> @@ -135,6 +136,20 @@ static int http_options(const char *var, const char *value, void *cb)
>        return git_default_config(var, value, cb);
>  }
>
> +static void init_curl_http_auth(CURL *result)
> +{
> +       if (!user_name)
> +               curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
> +       else {
> +               struct strbuf up = STRBUF_INIT;
> +               if (!user_pass)
> +                       user_pass = xstrdup(getpass("Password: "));
> +               strbuf_addf(&up, "%s:%s", user_name, user_pass);
> +               curl_easy_setopt(result, CURLOPT_USERPWD,
> +                                strbuf_detach(&up, NULL));
> +       }
> +}
> +

Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking
for LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
(curl-7.9.3-2ssl) which doesn't seem to have this option, so building
next is broken on AIX for me from this morning (c33976cb).

Is there a specific minimum version of curl we want to continue supporting?

Mike

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-12  8:53       ` Mike Ralphson
@ 2009-03-12  8:59         ` Daniel Stenberg
  2009-03-12  9:12           ` Mike Ralphson
  2009-03-13  5:53         ` Junio C Hamano
  1 sibling, 1 reply; 25+ messages in thread
From: Daniel Stenberg @ 2009-03-12  8:59 UTC (permalink / raw)
  To: Mike Ralphson; +Cc: Junio C Hamano, Mike Gaffney, git

On Thu, 12 Mar 2009, Mike Ralphson wrote:

> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking for 
> LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here 
> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building next 
> is broken on AIX for me from this morning (c33976cb).
>
> Is there a specific minimum version of curl we want to continue supporting?

May I suggest perhaps require a libcurl version that is no older than three 
years or something like that?

Perhaps this list can serve as some help:

 	http://curl.haxx.se/docs/releases.html

(spoiler: libcurl 7.9.3 is more than seven years old!)

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-12  8:59         ` Daniel Stenberg
@ 2009-03-12  9:12           ` Mike Ralphson
  2009-03-12  9:24             ` Daniel Stenberg
  0 siblings, 1 reply; 25+ messages in thread
From: Mike Ralphson @ 2009-03-12  9:12 UTC (permalink / raw)
  To: Daniel Stenberg; +Cc: Junio C Hamano, Mike Gaffney, git

2009/3/12 Daniel Stenberg <daniel@haxx.se>:
> On Thu, 12 Mar 2009, Mike Ralphson wrote:
>
>> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking for
>> LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
>> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building next
>> is broken on AIX for me from this morning (c33976cb).
>>
>> Is there a specific minimum version of curl we want to continue
>> supporting?
>
> May I suggest perhaps require a libcurl version that is no older than three
> years or something like that?

It might be a plan 8-) Though I was thinking technically in terms of
features we think git needs. Though doubtless there are several
security fixes it would be beneficial to keep up to date with.

> (spoiler: libcurl 7.9.3 is more than seven years old!)

And still the release IBM package for AIX [1]. 8-(

The summary of automatic builds (http://curl.haxx.se/auto/) is very
nicely presented. Is that custom code?

Thanks for curl, even the old versions!

Mike

[1] http://www-03.ibm.com/systems/power/software/aix/linux/toolbox/alpha.html

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-12  9:12           ` Mike Ralphson
@ 2009-03-12  9:24             ` Daniel Stenberg
  0 siblings, 0 replies; 25+ messages in thread
From: Daniel Stenberg @ 2009-03-12  9:24 UTC (permalink / raw)
  To: Mike Ralphson; +Cc: Junio C Hamano, Mike Gaffney, git

On Thu, 12 Mar 2009, Mike Ralphson wrote:

>> May I suggest perhaps require a libcurl version that is no older than three 
>> years or something like that?
>
> It might be a plan 8-) Though I was thinking technically in terms of 
> features we think git needs. Though doubtless there are several security 
> fixes it would be beneficial to keep up to date with.

Right, but if you set a common lowest denominator first you know what features 
to expect to be there _at least_, then there might of course be a set of 
additional ones brought by newer versions. It would reduce the amount of 
conditionals in the code and what-if-this-is-used scenarios (in the code and 
in support/docs). It also reduces the risks of git getting odd problems due to 
very old libcurl bugs.

>> (spoiler: libcurl 7.9.3 is more than seven years old!)
>
> And still the release IBM package for AIX [1]. 8-(

However, someone who's building/getting git might also be able to build/get a 
newer libcurl.

> The summary of automatic builds (http://curl.haxx.se/auto/) is very nicely 
> presented. Is that custom code?

The code is custom (perl) but present in the curl CVS repo for the web site 
and could probably fairly easy be adapted for other purposes/projects.

In the curl project we provide scripts for distributed automatic tests and 
then we have a central server that receives the reports by mail and the 
automatic summary script displays the status of those tests on that page.

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-12  8:53       ` Mike Ralphson
  2009-03-12  8:59         ` Daniel Stenberg
@ 2009-03-13  5:53         ` Junio C Hamano
  2009-03-13  7:58           ` Daniel Stenberg
                             ` (2 more replies)
  1 sibling, 3 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-13  5:53 UTC (permalink / raw)
  To: Mike Ralphson; +Cc: Mike Gaffney, git

Mike Ralphson <mike.ralphson@gmail.com> writes:

> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking
> for LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building
> next is broken on AIX for me from this morning (c33976cb).

Yeah, I did this as "How about doing it this way without adding a band-aid
configuration options" demonstration, and meant to clean it up (rather,
meant to wait for the original submitter to clean-up) before moving it
forward, but I forgot.  Sorry about that.

How does this look?

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in
7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I
am assuming it was available even in very early versions...

-- >8 --
From 750d9305009a0f3fd14c0b5c5e62ae1eb2b18fda Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 12 Mar 2009 22:34:43 -0700
Subject: [PATCH] http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient versions of cURL

Besides, we have already called easy_setopt with the option before coming
to this function if it was available, so there is no need to repeat it
here.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 http.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/http.c b/http.c
index b8f947e..2fc55d6 100644
--- a/http.c
+++ b/http.c
@@ -138,9 +138,7 @@ static int http_options(const char *var, const char *value, void *cb)
 
 static void init_curl_http_auth(CURL *result)
 {
-	if (!user_name)
-		curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
-	else {
+	if (user_name) {
 		struct strbuf up = STRBUF_INIT;
 		if (!user_pass)
 			user_pass = xstrdup(getpass("Password: "));
-- 
1.6.2.249.g770a0

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-13  5:53         ` Junio C Hamano
@ 2009-03-13  7:58           ` Daniel Stenberg
  2009-03-13 10:53           ` Mike Ralphson
  2009-03-13 12:47           ` Mike Gaffney
  2 siblings, 0 replies; 25+ messages in thread
From: Daniel Stenberg @ 2009-03-13  7:58 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Ralphson, Mike Gaffney, git

On Thu, 12 Mar 2009, Junio C Hamano wrote:

> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in 
> 7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I am 
> assuming it was available even in very early versions...

Yes it was.

Driven by use cases such as this, I also recently produced the 
"symbols-in-versions" document in the libcurl tree which should help apps to 
know what should works when:

http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup

-- 

  / daniel.haxx.se

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-13  5:53         ` Junio C Hamano
  2009-03-13  7:58           ` Daniel Stenberg
@ 2009-03-13 10:53           ` Mike Ralphson
  2009-03-14  5:55             ` Junio C Hamano
  2009-03-13 12:47           ` Mike Gaffney
  2 siblings, 1 reply; 25+ messages in thread
From: Mike Ralphson @ 2009-03-13 10:53 UTC (permalink / raw)
  To: Junio C Hamano, Daniel Stenberg; +Cc: Mike Gaffney, git

2009/3/13 Junio C Hamano <gitster@pobox.com>:
> Yeah, I did this as "How about doing it this way without adding a band-aid
> configuration options" demonstration, and meant to clean it up (rather,
> meant to wait for the original submitter to clean-up) before moving it
> forward, but I forgot.  Sorry about that.
>
> How does this look?

This patch fixes the build breakage for me, thanks. If I can find a
combination of AIX + working gcc + correct 32bit / non-broken 64bit
libraries + necessary Gnu tools + ancient curl + Apache2 in this maze
of twisty turny servers (all different) I'll give the http server
tests a whirl too.

2009/3/13 Daniel Stenberg <daniel@haxx.se>:
>Driven by use cases such as this, I also recently produced the
>"symbols-in-versions" document in the libcurl tree which should
> help apps to know what should works when:

> http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup

Very helpful, thanks.

Junio, if I check all the unprotected CURL* options against this list,
would that give us our absolute minimum supported version? If so,
would it then be ok to remove any unnecessary ifdefs for lower
versions if they exist?

Mike

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-13  5:53         ` Junio C Hamano
  2009-03-13  7:58           ` Daniel Stenberg
  2009-03-13 10:53           ` Mike Ralphson
@ 2009-03-13 12:47           ` Mike Gaffney
  2009-03-14  6:43             ` Junio C Hamano
  2 siblings, 1 reply; 25+ messages in thread
From: Mike Gaffney @ 2009-03-13 12:47 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Mike Ralphson, git

I was going to try and clean this up this weekend or early next week. I'm also
trying to encourage open source submissions at work and was using this
as an example patch to get people going (we need the fix to use git). So
I do plan finishing this, just have to do it when I have time.

Daniel, thanks for the link, I had been wondering what was introduced when in curl.

-Mike

Junio C Hamano wrote:
> Mike Ralphson <mike.ralphson@gmail.com> writes:
> 
>> Elsewhere we seem to protect use of CURL_NETRC_OPTIONAL by checking
>> for LIBCURL_VERSION_NUM >= 0x070907. I have an ancient curl here
>> (curl-7.9.3-2ssl) which doesn't seem to have this option, so building
>> next is broken on AIX for me from this morning (c33976cb).
> 
> Yeah, I did this as "How about doing it this way without adding a band-aid
> configuration options" demonstration, and meant to clean it up (rather,
> meant to wait for the original submitter to clean-up) before moving it
> forward, but I forgot.  Sorry about that.
> 
> How does this look?
> 
> http://curl.haxx.se/libcurl/c/curl_easy_setopt.html seems to say "added in
> 7.X.Y" for some options but does say when CURLOPT_USERPWD was added, so I
> am assuming it was available even in very early versions...
> 
> -- >8 --
> From 750d9305009a0f3fd14c0b5c5e62ae1eb2b18fda Mon Sep 17 00:00:00 2001
> From: Junio C Hamano <gitster@pobox.com>
> Date: Thu, 12 Mar 2009 22:34:43 -0700
> Subject: [PATCH] http.c: CURLOPT_NETRC_OPTIONAL is not available in ancient versions of cURL
> 
> Besides, we have already called easy_setopt with the option before coming
> to this function if it was available, so there is no need to repeat it
> here.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  http.c |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/http.c b/http.c
> index b8f947e..2fc55d6 100644
> --- a/http.c
> +++ b/http.c
> @@ -138,9 +138,7 @@ static int http_options(const char *var, const char *value, void *cb)
>  
>  static void init_curl_http_auth(CURL *result)
>  {
> -	if (!user_name)
> -		curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
> -	else {
> +	if (user_name) {
>  		struct strbuf up = STRBUF_INIT;
>  		if (!user_pass)
>  			user_pass = xstrdup(getpass("Password: "));

-- 
-Mike Gaffney (http://rdocul.us)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-13 10:53           ` Mike Ralphson
@ 2009-03-14  5:55             ` Junio C Hamano
  0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-14  5:55 UTC (permalink / raw)
  To: Mike Ralphson; +Cc: Daniel Stenberg, Mike Gaffney, git

Mike Ralphson <mike.ralphson@gmail.com> writes:

> 2009/3/13 Daniel Stenberg <daniel@haxx.se>:
>>Driven by use cases such as this, I also recently produced the
>>"symbols-in-versions" document in the libcurl tree which should
>> help apps to know what should works when:
>
>> http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> Very helpful, thanks.

Yeah, I wish we new about it much earlier.  Thanks, Daniel.

> Junio, if I check all the unprotected CURL* options against this list,
> would that give us our absolute minimum supported version? If so,
> would it then be ok to remove any unnecessary ifdefs for lower
> versions if they exist?

Sounds like a good plan.  Please get the ball rolling.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-13 12:47           ` Mike Gaffney
@ 2009-03-14  6:43             ` Junio C Hamano
  0 siblings, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-14  6:43 UTC (permalink / raw)
  To: Mike Gaffney; +Cc: Mike Ralphson, git

Mike Gaffney <mr.gaffo@gmail.com> writes:

> I was going to try and clean this up this weekend or early next week. I'm also
> trying to encourage open source submissions at work and was using this
> as an example patch to get people going (we need the fix to use git). So
> I do plan finishing this, just have to do it when I have time.

Thanks.

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-17 16:24   ` Daniel Barkalow
@ 2009-03-18 22:41     ` Amos King
  0 siblings, 0 replies; 25+ messages in thread
From: Amos King @ 2009-03-18 22:41 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: Junio C Hamano, git

I got push working.  I wanted to ask one thing before I submit.  I
know that it is nice to keep changes local.  There is a method in
remote.c called add_url, but it is not exposed.  Right now to keep the
changes local I moved the internals of that method inline, but is it
ok for me to expose that method instead?

Amos

PS - Junio sorry for the double send.  I didn't notice that we weren't
on the list.

On Tue, Mar 17, 2009 at 11:24 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Mon, 16 Mar 2009, Junio C Hamano wrote:
>
>> Amos King <amos.l.king@gmail.com> writes:
>>
>> > Junio,
>> >
>> > I'm working with Mike on the http auth stuff, and I was testing out
>> > your patch.  I can get it to work for fetch but push is giving me some
>> > grief.  Looking through the code I noticed that online 219 of
>> > http-push.c that http_init is being called with NULL instead of a
>> > remote.  If I pass in the remote then there is no remotre-url.  I've
>> > been digging around and can't find where or when that is being set.
>> > It has been a while since I worked with C but I'd love to jump in and
>> > help out here.  Can you point me in the right direction to get the
>> > remote->url[0] set for the http_auth_init to use?
>>
>> Daniel is the primary culprit who introduced the transport abstraction,
>> and I think he muttered something about his work-in-progress that involves
>> in some change in the API.  Perhaps he has some insights here?
>>
>> Naah.  I forgot that the transport abstraction on the fetch side is much
>> more integrated but curl_transport_push() simply launches http-push.c that
>> has a world on its own.  Worse yet, "remote" in http-push.c is not even
>> the "struct remote"; it is something private to http-push.c called "struct
>> repo".
>>
>> I am not sure how much work would be involved in converting (or if it is
>> even worth to convert) http-push.c to fit better into the transport API,
>> but if that is feasible, it might be a better longer-term solution.
>
> I think it would be a good thing to do. With the new transport push
> method, it could even get support for updating the tracking refs that
> track the refs you changed, since I broke that out of the git-native
> protocol code and into the transport code.
>
> My guess is that converting http-push to be called in-process would
> actually be pretty easy, because the two sides don't look at the same data
> currently. (Some things were tricky with fetch, because the same process
> sometimes wants to do fetches multiple times, for getting tags; this isn't
> as big a deal.)
>
> I think it should just be a matter of breaking http-push's main() into a
> function that deals with the http-push command line and a function that
> does the work, setting up a header file like send-pack.h, and changing
> transport.c to just call the function.
>
>> Right now, builtin-push.c does all the remote inspection and when
>> http-push is called, the latter gets the information at the lowest level
>> only; the higher level information such as what nickname was used by the
>> user to initiate the "git push" process and whether the refspecs came from
>> the command line or from the config are all lost, which is quite sad.
>
> What I did short-term for the send-pack version was introduce an optional
> command line argument, "--remote", that names the remote used, so the
> other program could get the configuration as well. It's a pretty easy
> step, but I don't think it's too worthwhile in this case.
>
>> But as a much lower impact interim solution, I suspect that you can fake a
>> minimally usable remote.  The http_push() codepath only cares about
>> remote->http_proxy and remote->url settings as far as I can tell, so
>> perhaps you can start (with a big warning that the remote you are creating
>> is a fake one) by filling the absolute minimum?
>>
>> That is, something along these lines (this comes on top of an obvious
>> patch that renames existing "remote" variable in http-push. to "repo").
>>
>> diff --git a/http-push.c b/http-push.c
>> index dfbb247..f04ac74 100644
>> --- a/http-push.c
>> +++ b/http-push.c
>> @@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
>>       int new_refs;
>>       struct ref *ref;
>>       char *rewritten_url = NULL;
>> +     struct remote *remote;
>>
>>       git_extract_argv0_path(argv[0]);
>>
>> @@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
>>       if (!repo->url)
>>               usage(http_push_usage);
>>
>> +     remote = remote_get(repo->url);
>> +
>>       if (delete_branch && nr_refspec != 1)
>>               die("You must specify only one branch name when deleting a remote branch");
>>
>>       memset(remote_dir_exists, -1, 256);
>>
>> -     http_init(NULL);
>> +     http_init(remote);
>>
>>       no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
>
> This should work, although it obviously won't figure out the proxy for the
> configuration for the remote that was actually used.
>
>        -Daniel
> *This .sig left intentionally blank*
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
  2009-03-17  6:27 ` Junio C Hamano
  2009-03-17  6:47   ` Junio C Hamano
@ 2009-03-17 16:24   ` Daniel Barkalow
  2009-03-18 22:41     ` Amos King
  1 sibling, 1 reply; 25+ messages in thread
From: Daniel Barkalow @ 2009-03-17 16:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Amos King, git

On Mon, 16 Mar 2009, Junio C Hamano wrote:

> Amos King <amos.l.king@gmail.com> writes:
> 
> > Junio,
> >
> > I'm working with Mike on the http auth stuff, and I was testing out
> > your patch.  I can get it to work for fetch but push is giving me some
> > grief.  Looking through the code I noticed that online 219 of
> > http-push.c that http_init is being called with NULL instead of a
> > remote.  If I pass in the remote then there is no remotre-url.  I've
> > been digging around and can't find where or when that is being set.
> > It has been a while since I worked with C but I'd love to jump in and
> > help out here.  Can you point me in the right direction to get the
> > remote->url[0] set for the http_auth_init to use?
> 
> Daniel is the primary culprit who introduced the transport abstraction,
> and I think he muttered something about his work-in-progress that involves
> in some change in the API.  Perhaps he has some insights here?
> 
> Naah.  I forgot that the transport abstraction on the fetch side is much
> more integrated but curl_transport_push() simply launches http-push.c that
> has a world on its own.  Worse yet, "remote" in http-push.c is not even
> the "struct remote"; it is something private to http-push.c called "struct
> repo".
>
> I am not sure how much work would be involved in converting (or if it is
> even worth to convert) http-push.c to fit better into the transport API,
> but if that is feasible, it might be a better longer-term solution.

I think it would be a good thing to do. With the new transport push 
method, it could even get support for updating the tracking refs that 
track the refs you changed, since I broke that out of the git-native 
protocol code and into the transport code.

My guess is that converting http-push to be called in-process would 
actually be pretty easy, because the two sides don't look at the same data 
currently. (Some things were tricky with fetch, because the same process 
sometimes wants to do fetches multiple times, for getting tags; this isn't 
as big a deal.)

I think it should just be a matter of breaking http-push's main() into a 
function that deals with the http-push command line and a function that 
does the work, setting up a header file like send-pack.h, and changing 
transport.c to just call the function.

> Right now, builtin-push.c does all the remote inspection and when
> http-push is called, the latter gets the information at the lowest level
> only; the higher level information such as what nickname was used by the
> user to initiate the "git push" process and whether the refspecs came from
> the command line or from the config are all lost, which is quite sad.

What I did short-term for the send-pack version was introduce an optional 
command line argument, "--remote", that names the remote used, so the 
other program could get the configuration as well. It's a pretty easy 
step, but I don't think it's too worthwhile in this case.

> But as a much lower impact interim solution, I suspect that you can fake a
> minimally usable remote.  The http_push() codepath only cares about
> remote->http_proxy and remote->url settings as far as I can tell, so
> perhaps you can start (with a big warning that the remote you are creating
> is a fake one) by filling the absolute minimum?
> 
> That is, something along these lines (this comes on top of an obvious
> patch that renames existing "remote" variable in http-push. to "repo").
> 
> diff --git a/http-push.c b/http-push.c
> index dfbb247..f04ac74 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
>  	int new_refs;
>  	struct ref *ref;
>  	char *rewritten_url = NULL;
> +	struct remote *remote;
>  
>  	git_extract_argv0_path(argv[0]);
>  
> @@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
>  	if (!repo->url)
>  		usage(http_push_usage);
>  
> +	remote = remote_get(repo->url);
> +
>  	if (delete_branch && nr_refspec != 1)
>  		die("You must specify only one branch name when deleting a remote branch");
>  
>  	memset(remote_dir_exists, -1, 256);
>  
> -	http_init(NULL);
> +	http_init(remote);
>  
>  	no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");

This should work, although it obviously won't figure out the proxy for the 
configuration for the remote that was actually used.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-17  6:27 ` Junio C Hamano
@ 2009-03-17  6:47   ` Junio C Hamano
  2009-03-17 16:24   ` Daniel Barkalow
  1 sibling, 0 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-17  6:47 UTC (permalink / raw)
  To: Amos King; +Cc: git, Daniel Barkalow

Junio C Hamano <gitster@pobox.com> writes:

> That is, something along these lines (this comes on top of an obvious
> patch that renames existing "remote" variable in http-push. to "repo").

And to save you the trouble, here is the "obvious" renaming patch, that
applies on top of 750d930 (http.c: CURLOPT_NETRC_OPTIONAL is not available
in ancient versions of cURL, 2009-03-12).

diff --git a/http-push.c b/http-push.c
index 30d2d34..dfbb247 100644
--- a/http-push.c
+++ b/http-push.c
@@ -97,7 +97,7 @@ struct repo
 	struct remote_lock *locks;
 };
 
-static struct repo *remote;
+static struct repo *repo;
 
 enum transfer_state {
 	NEED_FETCH,
@@ -324,7 +324,7 @@ static void start_fetch_loose(struct transfer_request *request)
 
 	git_SHA1_Init(&request->c);
 
-	url = get_remote_object_url(remote->url, hex, 0);
+	url = get_remote_object_url(repo->url, hex, 0);
 	request->url = xstrdup(url);
 
 	/* If a previous temp file is present, process what was already
@@ -389,7 +389,7 @@ static void start_fetch_loose(struct transfer_request *request)
 	request->state = RUN_FETCH_LOOSE;
 	if (!start_active_slot(slot)) {
 		fprintf(stderr, "Unable to start GET request\n");
-		remote->can_update_info_refs = 0;
+		repo->can_update_info_refs = 0;
 		release_request(request);
 	}
 }
@@ -399,7 +399,7 @@ static void start_mkcol(struct transfer_request *request)
 	char *hex = sha1_to_hex(request->obj->sha1);
 	struct active_request_slot *slot;
 
-	request->url = get_remote_object_url(remote->url, hex, 1);
+	request->url = get_remote_object_url(repo->url, hex, 1);
 
 	slot = get_active_slot();
 	slot->callback_func = process_response;
@@ -434,10 +434,10 @@ static void start_fetch_packed(struct transfer_request *request)
 	struct transfer_request *check_request = request_queue_head;
 	struct active_request_slot *slot;
 
-	target = find_sha1_pack(request->obj->sha1, remote->packs);
+	target = find_sha1_pack(request->obj->sha1, repo->packs);
 	if (!target) {
 		fprintf(stderr, "Unable to fetch %s, will not be able to update server info refs\n", sha1_to_hex(request->obj->sha1));
-		remote->can_update_info_refs = 0;
+		repo->can_update_info_refs = 0;
 		release_request(request);
 		return;
 	}
@@ -450,9 +450,9 @@ static void start_fetch_packed(struct transfer_request *request)
 	snprintf(request->tmpfile, sizeof(request->tmpfile),
 		 "%s.temp", filename);
 
-	url = xmalloc(strlen(remote->url) + 64);
+	url = xmalloc(strlen(repo->url) + 64);
 	sprintf(url, "%sobjects/pack/pack-%s.pack",
-		remote->url, sha1_to_hex(target->sha1));
+		repo->url, sha1_to_hex(target->sha1));
 
 	/* Make sure there isn't another open request for this pack */
 	while (check_request) {
@@ -469,7 +469,7 @@ static void start_fetch_packed(struct transfer_request *request)
 	if (!packfile) {
 		fprintf(stderr, "Unable to open local file %s for pack",
 			request->tmpfile);
-		remote->can_update_info_refs = 0;
+		repo->can_update_info_refs = 0;
 		free(url);
 		return;
 	}
@@ -505,7 +505,7 @@ static void start_fetch_packed(struct transfer_request *request)
 	request->state = RUN_FETCH_PACKED;
 	if (!start_active_slot(slot)) {
 		fprintf(stderr, "Unable to start GET request\n");
-		remote->can_update_info_refs = 0;
+		repo->can_update_info_refs = 0;
 		release_request(request);
 	}
 }
@@ -554,10 +554,10 @@ static void start_put(struct transfer_request *request)
 	request->buffer.buf.len = stream.total_out;
 
 	strbuf_addstr(&buf, "Destination: ");
-	append_remote_object_url(&buf, remote->url, hex, 0);
+	append_remote_object_url(&buf, repo->url, hex, 0);
 	request->dest = strbuf_detach(&buf, NULL);
 
-	append_remote_object_url(&buf, remote->url, hex, 0);
+	append_remote_object_url(&buf, repo->url, hex, 0);
 	strbuf_add(&buf, request->lock->tmpfile_suffix, 41);
 	request->url = strbuf_detach(&buf, NULL);
 
@@ -648,7 +648,7 @@ static int refresh_lock(struct remote_lock *lock)
 
 static void check_locks(void)
 {
-	struct remote_lock *lock = remote->locks;
+	struct remote_lock *lock = repo->locks;
 	time_t current_time = time(NULL);
 	int time_remaining;
 
@@ -788,7 +788,7 @@ static void finish_request(struct transfer_request *request)
 		if (request->curl_result != CURLE_OK) {
 			fprintf(stderr, "Unable to get pack file %s\n%s",
 				request->url, curl_errorstr);
-			remote->can_update_info_refs = 0;
+			repo->can_update_info_refs = 0;
 		} else {
 			off_t pack_size = ftell(request->local_stream);
 
@@ -798,7 +798,7 @@ static void finish_request(struct transfer_request *request)
 					       request->filename)) {
 				target = (struct packed_git *)request->userData;
 				target->pack_size = pack_size;
-				lst = &remote->packs;
+				lst = &repo->packs;
 				while (*lst != target)
 					lst = &((*lst)->next);
 				*lst = (*lst)->next;
@@ -806,7 +806,7 @@ static void finish_request(struct transfer_request *request)
 				if (!verify_pack(target))
 					install_packed_git(target);
 				else
-					remote->can_update_info_refs = 0;
+					repo->can_update_info_refs = 0;
 			}
 		}
 		release_request(request);
@@ -889,7 +889,7 @@ static int add_send_request(struct object *obj, struct remote_lock *lock)
 		get_remote_object_list(obj->sha1[0]);
 	if (obj->flags & (REMOTE | PUSHING))
 		return 0;
-	target = find_sha1_pack(obj->sha1, remote->packs);
+	target = find_sha1_pack(obj->sha1, repo->packs);
 	if (target) {
 		obj->flags |= REMOTE;
 		return 0;
@@ -930,8 +930,8 @@ static int fetch_index(unsigned char *sha1)
 	struct slot_results results;
 
 	/* Don't use the index if the pack isn't there */
-	url = xmalloc(strlen(remote->url) + 64);
-	sprintf(url, "%sobjects/pack/pack-%s.pack", remote->url, hex);
+	url = xmalloc(strlen(repo->url) + 64);
+	sprintf(url, "%sobjects/pack/pack-%s.pack", repo->url, hex);
 	slot = get_active_slot();
 	slot->results = &results;
 	curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -956,7 +956,7 @@ static int fetch_index(unsigned char *sha1)
 	if (push_verbosely)
 		fprintf(stderr, "Getting index for pack %s\n", hex);
 
-	sprintf(url, "%sobjects/pack/pack-%s.idx", remote->url, hex);
+	sprintf(url, "%sobjects/pack/pack-%s.idx", repo->url, hex);
 
 	filename = sha1_pack_index_name(sha1);
 	snprintf(tmpfile, sizeof(tmpfile), "%s.temp", filename);
@@ -1018,8 +1018,8 @@ static int setup_index(unsigned char *sha1)
 		return -1;
 
 	new_pack = parse_pack_index(sha1);
-	new_pack->next = remote->packs;
-	remote->packs = new_pack;
+	new_pack->next = repo->packs;
+	repo->packs = new_pack;
 	return 0;
 }
 
@@ -1037,8 +1037,8 @@ static int fetch_indices(void)
 	if (push_verbosely)
 		fprintf(stderr, "Getting pack list\n");
 
-	url = xmalloc(strlen(remote->url) + 20);
-	sprintf(url, "%sobjects/info/packs", remote->url);
+	url = xmalloc(strlen(repo->url) + 20);
+	sprintf(url, "%sobjects/info/packs", repo->url);
 
 	slot = get_active_slot();
 	slot->results = &results;
@@ -1223,11 +1223,11 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
 	struct curl_slist *dav_headers = NULL;
 	struct xml_ctx ctx;
 
-	url = xmalloc(strlen(remote->url) + strlen(path) + 1);
-	sprintf(url, "%s%s", remote->url, path);
+	url = xmalloc(strlen(repo->url) + strlen(path) + 1);
+	sprintf(url, "%s%s", repo->url, path);
 
 	/* Make sure leading directories exist for the remote ref */
-	ep = strchr(url + strlen(remote->url) + 1, '/');
+	ep = strchr(url + strlen(repo->url) + 1, '/');
 	while (ep) {
 		char saved_character = ep[1];
 		ep[1] = '\0';
@@ -1319,8 +1319,8 @@ static struct remote_lock *lock_remote(const char *path, long timeout)
 	} else {
 		lock->url = url;
 		lock->start_time = time(NULL);
-		lock->next = remote->locks;
-		remote->locks = lock;
+		lock->next = repo->locks;
+		repo->locks = lock;
 	}
 
 	return lock;
@@ -1330,7 +1330,7 @@ static int unlock_remote(struct remote_lock *lock)
 {
 	struct active_request_slot *slot;
 	struct slot_results results;
-	struct remote_lock *prev = remote->locks;
+	struct remote_lock *prev = repo->locks;
 	struct curl_slist *dav_headers;
 	int rc = 0;
 
@@ -1356,8 +1356,8 @@ static int unlock_remote(struct remote_lock *lock)
 
 	curl_slist_free_all(dav_headers);
 
-	if (remote->locks == lock) {
-		remote->locks = lock->next;
+	if (repo->locks == lock) {
+		repo->locks = lock->next;
 	} else {
 		while (prev && prev->next != lock)
 			prev = prev->next;
@@ -1375,7 +1375,7 @@ static int unlock_remote(struct remote_lock *lock)
 
 static void remove_locks(void)
 {
-	struct remote_lock *lock = remote->locks;
+	struct remote_lock *lock = repo->locks;
 
 	fprintf(stderr, "Removing remote locks...\n");
 	while (lock) {
@@ -1457,7 +1457,7 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
 				}
 			}
 			if (path) {
-				path += remote->path_len;
+				path += repo->path_len;
 				ls->dentry_name = xstrdup(path);
 			}
 		} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
@@ -1480,7 +1480,7 @@ static void remote_ls(const char *path, int flags,
 		      void (*userFunc)(struct remote_ls_ctx *ls),
 		      void *userData)
 {
-	char *url = xmalloc(strlen(remote->url) + strlen(path) + 1);
+	char *url = xmalloc(strlen(repo->url) + strlen(path) + 1);
 	struct active_request_slot *slot;
 	struct slot_results results;
 	struct strbuf in_buffer = STRBUF_INIT;
@@ -1496,7 +1496,7 @@ static void remote_ls(const char *path, int flags,
 	ls.userData = userData;
 	ls.userFunc = userFunc;
 
-	sprintf(url, "%s%s", remote->url, path);
+	sprintf(url, "%s%s", repo->url, path);
 
 	strbuf_addf(&out_buffer.buf, PROPFIND_ALL_REQUEST);
 
@@ -1574,7 +1574,7 @@ static int locking_available(void)
 	struct xml_ctx ctx;
 	int lock_flags = 0;
 
-	strbuf_addf(&out_buffer.buf, PROPFIND_SUPPORTEDLOCK_REQUEST, remote->url);
+	strbuf_addf(&out_buffer.buf, PROPFIND_SUPPORTEDLOCK_REQUEST, repo->url);
 
 	dav_headers = curl_slist_append(dav_headers, "Depth: 0");
 	dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
@@ -1586,7 +1586,7 @@ static int locking_available(void)
 	curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
 	curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
 	curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_buffer);
-	curl_easy_setopt(slot->curl, CURLOPT_URL, remote->url);
+	curl_easy_setopt(slot->curl, CURLOPT_URL, repo->url);
 	curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
 	curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PROPFIND);
 	curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
@@ -1617,15 +1617,15 @@ static int locking_available(void)
 			XML_ParserFree(parser);
 			if (!lock_flags)
 				error("Error: no DAV locking support on %s",
-				      remote->url);
+				      repo->url);
 
 		} else {
 			error("Cannot access URL %s, return code %d",
-			      remote->url, results.curl_result);
+			      repo->url, results.curl_result);
 			lock_flags = 0;
 		}
 	} else {
-		error("Unable to start PROPFIND request on %s", remote->url);
+		error("Unable to start PROPFIND request on %s", repo->url);
 	}
 
 	strbuf_release(&out_buffer.buf);
@@ -1814,10 +1814,10 @@ static void one_remote_ref(char *refname)
 
 	ref = alloc_ref(refname);
 
-	if (http_fetch_ref(remote->url, ref) != 0) {
+	if (http_fetch_ref(repo->url, ref) != 0) {
 		fprintf(stderr,
 			"Unable to fetch ref %s from %s\n",
-			refname, remote->url);
+			refname, repo->url);
 		free(ref);
 		return;
 	}
@@ -1826,7 +1826,7 @@ static void one_remote_ref(char *refname)
 	 * Fetch a copy of the object if it doesn't exist locally - it
 	 * may be required for updating server info later.
 	 */
-	if (remote->can_update_info_refs && !has_sha1_file(ref->old_sha1)) {
+	if (repo->can_update_info_refs && !has_sha1_file(ref->old_sha1)) {
 		obj = lookup_unknown_object(ref->old_sha1);
 		if (obj) {
 			fprintf(stderr,	"  fetch %s for %s\n",
@@ -1921,10 +1921,10 @@ static void add_remote_info_ref(struct remote_ls_ctx *ls)
 
 	ref = alloc_ref(ls->dentry_name);
 
-	if (http_fetch_ref(remote->url, ref) != 0) {
+	if (http_fetch_ref(repo->url, ref) != 0) {
 		fprintf(stderr,
 			"Unable to fetch ref %s from %s\n",
-			ls->dentry_name, remote->url);
+			ls->dentry_name, repo->url);
 		aborted = 1;
 		free(ref);
 		return;
@@ -1999,12 +1999,12 @@ static void update_remote_info_refs(struct remote_lock *lock)
 
 static int remote_exists(const char *path)
 {
-	char *url = xmalloc(strlen(remote->url) + strlen(path) + 1);
+	char *url = xmalloc(strlen(repo->url) + strlen(path) + 1);
 	struct active_request_slot *slot;
 	struct slot_results results;
 	int ret = -1;
 
-	sprintf(url, "%s%s", remote->url, path);
+	sprintf(url, "%s%s", repo->url, path);
 
 	slot = get_active_slot();
 	slot->results = &results;
@@ -2034,8 +2034,8 @@ static void fetch_symref(const char *path, char **symref, unsigned char *sha1)
 	struct active_request_slot *slot;
 	struct slot_results results;
 
-	url = xmalloc(strlen(remote->url) + strlen(path) + 1);
-	sprintf(url, "%s%s", remote->url, path);
+	url = xmalloc(strlen(repo->url) + strlen(path) + 1);
+	sprintf(url, "%s%s", repo->url, path);
 
 	slot = get_active_slot();
 	slot->results = &results;
@@ -2150,7 +2150,7 @@ static int delete_remote_branch(char *pattern, int force)
 				     "of your current HEAD.\n"
 				     "If you are sure you want to delete it,"
 				     " run:\n\t'git http-push -D %s %s'",
-				     remote_ref->name, remote->url, pattern);
+				     remote_ref->name, repo->url, pattern);
 		}
 	}
 
@@ -2158,8 +2158,8 @@ static int delete_remote_branch(char *pattern, int force)
 	fprintf(stderr, "Removing remote branch '%s'\n", remote_ref->name);
 	if (dry_run)
 		return 0;
-	url = xmalloc(strlen(remote->url) + strlen(remote_ref->name) + 1);
-	sprintf(url, "%s%s", remote->url, remote_ref->name);
+	url = xmalloc(strlen(repo->url) + strlen(remote_ref->name) + 1);
+	sprintf(url, "%s%s", repo->url, remote_ref->name);
 	slot = get_active_slot();
 	slot->results = &results;
 	curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
@@ -2202,7 +2202,7 @@ int main(int argc, char **argv)
 
 	setup_git_directory();
 
-	remote = xcalloc(sizeof(*remote), 1);
+	repo = xcalloc(sizeof(*repo), 1);
 
 	argv++;
 	for (i = 1; i < argc; i++, argv++) {
@@ -2235,14 +2235,14 @@ int main(int argc, char **argv)
 				continue;
 			}
 		}
-		if (!remote->url) {
+		if (!repo->url) {
 			char *path = strstr(arg, "//");
-			remote->url = arg;
-			remote->path_len = strlen(arg);
+			repo->url = arg;
+			repo->path_len = strlen(arg);
 			if (path) {
-				remote->path = strchr(path+2, '/');
-				if (remote->path)
-					remote->path_len = strlen(remote->path);
+				repo->path = strchr(path+2, '/');
+				if (repo->path)
+					repo->path_len = strlen(repo->path);
 			}
 			continue;
 		}
@@ -2255,7 +2255,7 @@ int main(int argc, char **argv)
 	die("git-push is not available for http/https repository when not compiled with USE_CURL_MULTI");
 #endif
 
-	if (!remote->url)
+	if (!repo->url)
 		usage(http_push_usage);
 
 	if (delete_branch && nr_refspec != 1)
@@ -2267,13 +2267,13 @@ int main(int argc, char **argv)
 
 	no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
 
-	if (remote->url && remote->url[strlen(remote->url)-1] != '/') {
-		rewritten_url = xmalloc(strlen(remote->url)+2);
-		strcpy(rewritten_url, remote->url);
+	if (repo->url && repo->url[strlen(repo->url)-1] != '/') {
+		rewritten_url = xmalloc(strlen(repo->url)+2);
+		strcpy(rewritten_url, repo->url);
 		strcat(rewritten_url, "/");
-		remote->path = rewritten_url + (remote->path - remote->url);
-		remote->path_len++;
-		remote->url = rewritten_url;
+		repo->path = rewritten_url + (repo->path - repo->url);
+		repo->path_len++;
+		repo->url = rewritten_url;
 	}
 
 	/* Verify DAV compliance/lock support */
@@ -2285,20 +2285,20 @@ int main(int argc, char **argv)
 	sigchain_push_common(remove_locks_on_signal);
 
 	/* Check whether the remote has server info files */
-	remote->can_update_info_refs = 0;
-	remote->has_info_refs = remote_exists("info/refs");
-	remote->has_info_packs = remote_exists("objects/info/packs");
-	if (remote->has_info_refs) {
+	repo->can_update_info_refs = 0;
+	repo->has_info_refs = remote_exists("info/refs");
+	repo->has_info_packs = remote_exists("objects/info/packs");
+	if (repo->has_info_refs) {
 		info_ref_lock = lock_remote("info/refs", LOCK_TIME);
 		if (info_ref_lock)
-			remote->can_update_info_refs = 1;
+			repo->can_update_info_refs = 1;
 		else {
 			fprintf(stderr, "Error: cannot lock existing info/refs\n");
 			rc = 1;
 			goto cleanup;
 		}
 	}
-	if (remote->has_info_packs)
+	if (repo->has_info_packs)
 		fetch_indices();
 
 	/* Get a list of all local and remote heads to validate refspecs */
@@ -2456,8 +2456,8 @@ int main(int argc, char **argv)
 	}
 
 	/* Update remote server info if appropriate */
-	if (remote->has_info_refs && new_refs) {
-		if (info_ref_lock && remote->can_update_info_refs) {
+	if (repo->has_info_refs && new_refs) {
+		if (info_ref_lock && repo->can_update_info_refs) {
 			fprintf(stderr, "Updating remote server info\n");
 			if (!dry_run)
 				update_remote_info_refs(info_ref_lock);
@@ -2470,7 +2470,7 @@ int main(int argc, char **argv)
 	free(rewritten_url);
 	if (info_ref_lock)
 		unlock_remote(info_ref_lock);
-	free(remote);
+	free(repo);
 
 	curl_slist_free_all(no_pragma_header);
 

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH][v2] http authentication via prompts (with correct line  lengths)
  2009-03-17  5:15 Amos King
@ 2009-03-17  6:27 ` Junio C Hamano
  2009-03-17  6:47   ` Junio C Hamano
  2009-03-17 16:24   ` Daniel Barkalow
  0 siblings, 2 replies; 25+ messages in thread
From: Junio C Hamano @ 2009-03-17  6:27 UTC (permalink / raw)
  To: Amos King; +Cc: git, Daniel Barkalow

Amos King <amos.l.king@gmail.com> writes:

> Junio,
>
> I'm working with Mike on the http auth stuff, and I was testing out
> your patch.  I can get it to work for fetch but push is giving me some
> grief.  Looking through the code I noticed that online 219 of
> http-push.c that http_init is being called with NULL instead of a
> remote.  If I pass in the remote then there is no remotre-url.  I've
> been digging around and can't find where or when that is being set.
> It has been a while since I worked with C but I'd love to jump in and
> help out here.  Can you point me in the right direction to get the
> remote->url[0] set for the http_auth_init to use?

Daniel is the primary culprit who introduced the transport abstraction,
and I think he muttered something about his work-in-progress that involves
in some change in the API.  Perhaps he has some insights here?

Naah.  I forgot that the transport abstraction on the fetch side is much
more integrated but curl_transport_push() simply launches http-push.c that
has a world on its own.  Worse yet, "remote" in http-push.c is not even
the "struct remote"; it is something private to http-push.c called "struct
repo".

I am not sure how much work would be involved in converting (or if it is
even worth to convert) http-push.c to fit better into the transport API,
but if that is feasible, it might be a better longer-term solution.
Right now, builtin-push.c does all the remote inspection and when
http-push is called, the latter gets the information at the lowest level
only; the higher level information such as what nickname was used by the
user to initiate the "git push" process and whether the refspecs came from
the command line or from the config are all lost, which is quite sad.

But as a much lower impact interim solution, I suspect that you can fake a
minimally usable remote.  The http_push() codepath only cares about
remote->http_proxy and remote->url settings as far as I can tell, so
perhaps you can start (with a big warning that the remote you are creating
is a fake one) by filling the absolute minimum?

That is, something along these lines (this comes on top of an obvious
patch that renames existing "remote" variable in http-push. to "repo").

diff --git a/http-push.c b/http-push.c
index dfbb247..f04ac74 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
 	int new_refs;
 	struct ref *ref;
 	char *rewritten_url = NULL;
+	struct remote *remote;
 
 	git_extract_argv0_path(argv[0]);
 
@@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
 	if (!repo->url)
 		usage(http_push_usage);
 
+	remote = remote_get(repo->url);
+
 	if (delete_branch && nr_refspec != 1)
 		die("You must specify only one branch name when deleting a remote branch");
 
 	memset(remote_dir_exists, -1, 256);
 
-	http_init(NULL);
+	http_init(remote);
 
 	no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
 

^ permalink raw reply related	[flat|nested] 25+ messages in thread

* [PATCH][v2] http authentication via prompts (with correct line  lengths)
@ 2009-03-17  5:15 Amos King
  2009-03-17  6:27 ` Junio C Hamano
  0 siblings, 1 reply; 25+ messages in thread
From: Amos King @ 2009-03-17  5:15 UTC (permalink / raw)
  To: git

Junio,

I'm working with Mike on the http auth stuff, and I was testing out
your patch.  I can get it to work for fetch but push is giving me some
grief.  Looking through the code I noticed that online 219 of
http-push.c that http_init is being called with NULL instead of a
remote.  If I pass in the remote then there is no remotre-url.  I've
been digging around and can't find where or when that is being set.
It has been a while since I worked with C but I'd love to jump in and
help out here.  Can you point me in the right direction to get the
remote->url[0] set for the http_auth_init to use?

Thanks,

-- 
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2009-03-18 22:51 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-10  0:08 [PATCH][v2] http authentication via prompts (with correct line lengths) Mike Gaffney
2009-03-10  0:37 ` Junio C Hamano
2009-03-10  0:45   ` Johannes Schindelin
2009-03-10  3:25     ` Mike Gaffney
2009-03-10 10:43       ` Johannes Schindelin
2009-03-10 15:33         ` Mike Gaffney
2009-03-10  4:46   ` Mike Gaffney
2009-03-10  6:34     ` Junio C Hamano
2009-03-10  8:08       ` Daniel Stenberg
2009-03-10  8:35         ` Junio C Hamano
2009-03-12  8:53       ` Mike Ralphson
2009-03-12  8:59         ` Daniel Stenberg
2009-03-12  9:12           ` Mike Ralphson
2009-03-12  9:24             ` Daniel Stenberg
2009-03-13  5:53         ` Junio C Hamano
2009-03-13  7:58           ` Daniel Stenberg
2009-03-13 10:53           ` Mike Ralphson
2009-03-14  5:55             ` Junio C Hamano
2009-03-13 12:47           ` Mike Gaffney
2009-03-14  6:43             ` Junio C Hamano
2009-03-17  5:15 Amos King
2009-03-17  6:27 ` Junio C Hamano
2009-03-17  6:47   ` Junio C Hamano
2009-03-17 16:24   ` Daniel Barkalow
2009-03-18 22:41     ` Amos King

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.