threads / patch / 1949

patch, 3 partsSupport for SSL client cert

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

## tl;dr

12 messages between Sep 26, 2005 and Sep 28, 2005. Diffs are folded; open one to read it.

replies: 11people: 9as markdown or json

Nick Hengeveld· Sep 26, 2005, 17:51 UTC · lore
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
Show changes to http-fetch.c +27 −1
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
Petr Baudis· Sep 26, 2005, 18:23 UTC · re: Nick Hengeveld · lore

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

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...

Show 21 quoted lines
> @@ -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.
Nick Hengeveld· Sep 26, 2005, 18:36 UTC · re: Petr Baudis · lore

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

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.
Junio C Hamano· Sep 26, 2005, 20:43 UTC · re: Petr Baudis · lore

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

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.

Nick Hengeveld· Sep 27, 2005, 00:15 UTC · re: Junio C Hamano · lore

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

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.
Junio C Hamano· Sep 27, 2005, 00:43 UTC · re: Nick Hengeveld · lore

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?

Ameer Armaly· Sep 27, 2005, 00:57 UTC · re: Junio C Hamano · lore

Re: More Porcelains?

----- 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?
Show 15 quoted lines
> 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.

Show 5 quoted lines
>
> -
> 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 
Daniel Barkalow· Sep 27, 2005, 06:15 UTC · re: Junio C Hamano · lore

Re: More Porcelains?

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*
Catalin Marinas· Sep 27, 2005, 08:16 UTC · re: Junio C Hamano · lore

Re: More Porcelains?

Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> 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
Mariano Videla· Sep 27, 2005, 17:02 UTC · re: Catalin Marinas · lore

Re: More Porcelains?

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:
Show 12 quoted lines
> 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 ;-)
> 
Vincent Hanquez· Sep 28, 2005, 11:30 UTC · re: Junio C Hamano · lore

Re: More Porcelains?

On Mon, Sep 26, 2005 at 05:43:46PM -0700, Junio C Hamano wrote:
Show 7 quoted lines
> 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
Matthias Urlichs· Sep 28, 2005, 20:22 UTC · re: Junio C Hamano · lore

Re: More Porcelains?

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.

← back to recent threads