[PATCH 1/3] Support for SSL client cert

[PATCH 1/3] Support for SSL client cert

[Nick Hengeveld]

Added SSL client args and CURL settings

Signed-off-by: Nick Hengeveld <nickh@reactrix.com>


---

 http-fetch.c |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

2d293c34fdfde8a394b5f8a5c5343d9caf363bcc
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -476,6 +476,10 @@ int main(int argc, char **argv)
 	char *commit_id;
 	char *url;
 	int arg = 1;
+	char *ssl_cert = NULL;
+	char *ssl_key = NULL;
+	char *ssl_capath = NULL;
+	char *ssl_cacert = NULL;
 
 	while (arg < argc && argv[arg][0] == '-') {
 		if (argv[arg][1] == 't') {
@@ -491,11 +495,19 @@ int main(int argc, char **argv)
 		} else if (argv[arg][1] == 'w') {
 			write_ref = argv[arg + 1];
 			arg++;
+		} else if (arg+1 < argc && !strcmp(argv[arg], "--cert")) {
+			ssl_cert = argv[++arg];
+		} else if (arg+1 < argc && !strcmp(argv[arg], "--key")) {
+			ssl_key = argv[++arg];
+		} else if (arg+1 < argc && !strcmp(argv[arg], "--capath")) {
+			ssl_capath = argv[++arg];
+		} else if (arg+1 < argc && !strcmp(argv[arg], "--cacert")) {
+			ssl_cacert = argv[++arg];
 		}
 		arg++;
 	}
 	if (argc < arg + 2) {
-		usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
+		usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] [--cert ssl-cert-file] [--key ssl-key-file] [--capath CA-dir] [--cacert CA-cert-file] commit-id url");
 		return 1;
 	}
 	commit_id = argv[arg];
@@ -506,6 +518,20 @@ int main(int argc, char **argv)
 	curl = curl_easy_init();
 	no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
 
+        /* Set SSL parameters if they were provided */
+	if (ssl_cert != NULL) {
+		curl_easy_setopt(curl, CURLOPT_SSLCERT, ssl_cert);
+	}
+	if (ssl_key != NULL) {
+		curl_easy_setopt(curl, CURLOPT_SSLKEY, ssl_key);
+	}
+	if (ssl_capath != NULL) {
+		curl_easy_setopt(curl, CURLOPT_CAPATH, ssl_capath);
+	}
+	if (ssl_cacert != NULL) {
+		curl_easy_setopt(curl, CURLOPT_CAINFO, ssl_cacert);
+	}
+
 	curl_ssl_verify = getenv("GIT_SSL_NO_VERIFY") ? 0 : 1;
 	curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify);
 #if LIBCURL_VERSION_NUM >= 0x070907

Re: [PATCH 1/3] Support for SSL client cert

[Petr Baudis]

Dear diary, on Mon, Sep 26, 2005 at 07:51:57PM CEST, I got a letter
where Nick Hengeveld <nickh@reactrix.com> told me that...
> @@ -491,11 +495,19 @@ int main(int argc, char **argv)
>  		} else if (argv[arg][1] == 'w') {
>  			write_ref = argv[arg + 1];
>  			arg++;
> +		} else if (arg+1 < argc && !strcmp(argv[arg], "--cert")) {
> +			ssl_cert = argv[++arg];
> +		} else if (arg+1 < argc && !strcmp(argv[arg], "--key")) {
> +			ssl_key = argv[++arg];
> +		} else if (arg+1 < argc && !strcmp(argv[arg], "--capath")) {
> +			ssl_capath = argv[++arg];
> +		} else if (arg+1 < argc && !strcmp(argv[arg], "--cacert")) {
> +			ssl_cacert = argv[++arg];
>  		}
>  		arg++;
>  	}
>  	if (argc < arg + 2) {
> -		usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] commit-id url");
> +		usage("git-http-fetch [-c] [-t] [-a] [-d] [-v] [--recover] [-w ref] [--cert ssl-cert-file] [--key ssl-key-file] [--capath CA-dir] [--cacert CA-cert-file] commit-id url");
>  		return 1;
>  	}
>  	commit_id = argv[arg];

Could we please have at least --sslkey, if not having 'ssl' prepended to
all of them? You never know when you'll want to call something else like
that in the future... ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [PATCH 1/3] Support for SSL client cert

[Nick Hengeveld]

On Mon, Sep 26, 2005 at 08:23:41PM +0200, Petr Baudis wrote:

> Could we please have at least --sslkey, if not having 'ssl' prepended to
> all of them? You never know when you'll want to call something else like
> that in the future... ;-)

Makes sense - I wasn't comfortable deciding what those parameters should be
so I used the curl command-line options.  Who gets to make the official
call on that?

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

Re: [PATCH 1/3] Support for SSL client cert

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> writes:

> Could we please have at least --sslkey, if not having 'ssl' prepended to
> all of them? You never know when you'll want to call something else like
> that in the future... ;-)

That is a valid concern.

Anoter possibility is to read them from the environment, since
we already do SSL_NO_VERIFY from there.

If we go that route, it might make sense to have something like
the following in .git/remotes/that-site file:

    URL: https://some.company.site.xz
    ENV: GIT_SSL_KEY='/home/user/.ssl/'My ssl key'
    ENV: GIT_SSL_CERT='/home/user/.ssl/certs/My Certificate'
    ENV: GIT_SSL_CAPATH='/home/user/.ssl/My CA'
    ...

then at the beginning of git-fetch, we could eval these ENV
lines.

Re: [PATCH 1/3] Support for SSL client cert

[Nick Hengeveld]

On Mon, Sep 26, 2005 at 01:43:39PM -0700, Junio C Hamano wrote:

> That is a valid concern.
> 
> Anoter possibility is to read them from the environment, since
> we already do SSL_NO_VERIFY from there.

Good point - use of environment variables is more consistent.  Use of
command-line arguments is a bit more convenient in my case since I'm
driving the transfer from a perl script, but I suppose consistency is
more important...

-- 
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.

More Porcelains?

[Junio C Hamano]

Nick Hengeveld <nickh@reactrix.com> writes:

> Good point - use of environment variables is more consistent.  Use of
> command-line arguments is a bit more convenient in my case since I'm
> driving the transfer from a perl script, but I suppose consistency is
> more important...

Now you made me curious.

How many of you are working on your own Porcelains, announced or
unannounced?  I know about Cogito and StGIT ;-).  In a distant
past I have heard of something called JIT but I think it is now
defunct.  Matthias Urlichs said he is doing something with
Python.  Anybody else?

Re: More Porcelains?

[Ameer Armaly]

----- Original Message ----- 
From: "Junio C Hamano" <junkio@cox.net>
To: <git@vger.kernel.org>
Cc: "Nick Hengeveld" <nickh@reactrix.com>
Sent: Monday, September 26, 2005 8:43 PM
Subject: More Porcelains?


> Nick Hengeveld <nickh@reactrix.com> writes:
>
>> Good point - use of environment variables is more consistent.  Use of
>> command-line arguments is a bit more convenient in my case since I'm
>> driving the transfer from a perl script, but I suppose consistency is
>> more important...
>
> Now you made me curious.
>
> How many of you are working on your own Porcelains, announced or
> unannounced?  I know about Cogito and StGIT ;-).  In a distant
> past I have heard of something called JIT but I think it is now
> defunct.  Matthias Urlichs said he is doing something with
> Python.  Anybody else?
>
I am seriously looking at putting one together in the D language 
(http://www.digitalmars.com/d) <plug>, though it doesn't actually do 
anything as of yet, since I have to balance classes along with it.
>
> -
> 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 

Re: More Porcelains?

[Daniel Barkalow]

On Mon, 26 Sep 2005, Junio C Hamano wrote:

> How many of you are working on your own Porcelains, announced or
> unannounced?

I don't have a porcelain, but I organize my working trees/repository in a 
non-standard way, using an additional script (which creates a new working 
tree linked to an existing repository). 

I've also got a set of scripts for splitting up a patch into a series, 
which I've still not gotten around to cleaning up and submitting.

For the way I structure my working trees, it would be really helpful if 
all of the miscellaneous things that should stay with a repository (such 
as remotes) were in a single subdirectory of .git, so that I could just 
have a third symlink and have it all work, rather than needing a bunch of 
additional links.

	-Daniel
*This .sig left intentionally blank*

Re: More Porcelains?

[Catalin Marinas]

Junio C Hamano <junkio@cox.net> wrote:
> How many of you are working on your own Porcelains, announced or
> unannounced?  I know about Cogito and StGIT ;-).  In a distant
> past I have heard of something called JIT but I think it is now
> defunct.  Matthias Urlichs said he is doing something with
> Python.  Anybody else?

I just found gipy on sf.net - http://sourceforge.net/projects/gipy.

There are no files uploaded yet but hopefully I can soon 'steal' some
code for StGIT ;-)

-- 
Catalin

Re: More Porcelains?

[Mariano Videla]

Mmm...It's no porcelain.

I setup a git repository for gipy... Didn't upload any files in
sourceforge because I don't think is ready.

http://24.232.198.9:7978/gipy.git
http://24.232.198.9:7978/cgi/gitweb.cgi

By the way... you can 'steel' it all!

Mariano

On mar, 2005-09-27 at 09:16 +0100, Catalin Marinas wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> > How many of you are working on your own Porcelains, announced or
> > unannounced?  I know about Cogito and StGIT ;-).  In a distant
> > past I have heard of something called JIT but I think it is now
> > defunct.  Matthias Urlichs said he is doing something with
> > Python.  Anybody else?
> 
> I just found gipy on sf.net - http://sourceforge.net/projects/gipy.
> 
> There are no files uploaded yet but hopefully I can soon 'steal' some
> code for StGIT ;-)
> 

Re: More Porcelains?

[Vincent Hanquez]

On Mon, Sep 26, 2005 at 05:43:46PM -0700, Junio C Hamano wrote:
> Now you made me curious.
> 
> How many of you are working on your own Porcelains, announced or
> unannounced?  I know about Cogito and StGIT ;-).  In a distant
> past I have heard of something called JIT but I think it is now
> defunct.  Matthias Urlichs said he is doing something with
> Python.  Anybody else?

Hi Junio,

Well, I kinda work on one written in C using a libgit (using exec of git
executable for the moment) It doesn't do that much at the moment:
commiting, adding files, removing files.

At some point I'ld like to have a very integrated and easy to use
porcelain, but for now that's more a learning git by practice kind of
project.

Cheers,
-- 
Vincent Hanquez

Re: More Porcelains?

[Matthias Urlichs]

Hi, Junio C Hamano wrote:

> Matthias Urlichs said he is doing something with Python

Python integration needs either lots of fork+exec, a git rewrite in
Python, or a libgit reorganization in library-ized C.

I'm doing the latter, but my free time is kindof limited for now.

My library-ize branch is at 
	git fetch http://netz.smurf.noris.de/git/git.git libize
if anybody wants to have a look. My first goal is to get object access
working sanely (because that's what I need for my Python project).

I haven't merged up for some time, though.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Paul's Law:
	In America, it's not how much an item costs, it's how much you save.