{"thread":{"id":"19816","subject":"[PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","startedAt":"2009-06-15T02:39:00Z","lastAt":"2009-06-18T16:26:11Z","messageCount":11,"participants":["Mark Lodato","Junio C Hamano","Tay Ray Chuan","Karsten Weiss","Mike Ralphson"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"116306","messageId":"1245033541-15558-1-git-send-email-lodatom@gmail.com","threadId":"19816","inReplyTo":null,"subject":"[PATCH 1/2] http.c: fix compiling with libcurl 7.9.2","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-15T02:39:00Z","receivedAt":"2009-06-15T02:39:00Z","isPatch":true,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"Change the minimimum required libcurl version for the http.sslKey option\nto 7.9.3. Previously, preprocessor macros checked for >= 7.9.2, which\nis incorrect because CURLOPT_SSLKEY was introduced in 7.9.3. This now\nallows git to compile with libcurl 7.9.2.\n\nSigned-off-by: Mark Lodato \n---\n\nThis patch series is independent of my other password prompting patch\nseries, and is based off 'next', which includes Tay Ray Chuan's recent\nhttp changes.\n\nNote that git still does not compile on libcurl before 7.9.1 or below,\nsince CURLOPT_FTP_USE_EPSV (http.c:236) is defined in libcurl 7.9.2.\n\nOne question: In http.c, there are unnecessary #if LIBCURL_VERSION_NUM's\nsurrounding the global variable declarations, in http_options(), and in\nhttp_init(). Is there a reason why these exist? If not, I think\nremoving them would make the code easier to read.\n\nAny feedback or suggestions are appreciated!\nMark\n\n\n http.c | 8 ++++----\n 1 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/http.c b/http.c\nindex 95b2137..b049948 100644\n--- a/http.c\n+++ b/http.c\n@@ -20,7 +20,7 @@ char curl_errorstr[CURL_ERROR_SIZE];\n \n static int curl_ssl_verify = -1;\n static const char *ssl_cert;\n-#if LIBCURL_VERSION_NUM >= 0x070902\n+#if LIBCURL_VERSION_NUM >= 0x070903\n static const char *ssl_key;\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n@@ -126,7 +126,7 @@ static int http_options(const char *var, const char *value, void *cb)\n \t}\n \tif (!strcmp(\"http.sslcert\", var))\n \t\treturn git_config_string(&ssl_cert, var, value);\n-#if LIBCURL_VERSION_NUM >= 0x070902\n+#if LIBCURL_VERSION_NUM >= 0x070903\n \tif (!strcmp(\"http.sslkey\", var))\n \t\treturn git_config_string(&ssl_key, var, value);\n #endif\n@@ -196,7 +196,7 @@ static CURL *get_curl_handle(void)\n \n \tif (ssl_cert != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLCERT, ssl_cert);\n-#if LIBCURL_VERSION_NUM >= 0x070902\n+#if LIBCURL_VERSION_NUM >= 0x070903\n \tif (ssl_key != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLKEY, ssl_key);\n #endif\n@@ -313,7 +313,7 @@ void http_init(struct remote *remote)\n \t\tcurl_ssl_verify = 0;\n \n \tset_from_env(&ssl_cert, \"GIT_SSL_CERT\");\n-#if LIBCURL_VERSION_NUM >= 0x070902\n+#if LIBCURL_VERSION_NUM >= 0x070903\n \tset_from_env(&ssl_key, \"GIT_SSL_KEY\");\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n-- \n1.6.3.2\n"},{"id":"116305","messageId":"1245033541-15558-2-git-send-email-lodatom@gmail.com","threadId":"19816","inReplyTo":"1245033541-15558-1-git-send-email-lodatom@gmail.com","subject":"[PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-15T02:39:01Z","receivedAt":"2009-06-15T02:39:01Z","isPatch":true,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"Add two new configuration variables, http.sslCertType and\nhttp.sslKeyType, which tell libcurl the filetype for the SSL client\ncertificate and private key, respectively. The main benefit is to allow\nPKCS12 certificates for users with libcurl >= 7.13.0.\n\nSigned-off-by: Mark Lodato \n---\n\nUnfortunately, P12 support in libcurl is not great, so encrypted P12\ncertificates do not work at all. At least now unencrypted certificates\nare possible. Hopefully, my password prompting patch series (once I\nfinish it) will resolve this issue.\n\nAs always, any feedback on this patch is appreciated. In particular, I\nwelcome suggestions for improving the documentation phrasing.\n\n Documentation/config.txt | 10 ++++++++++\n http.c | 12 ++++++++++++\n 2 files changed, 22 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 2fecbe3..b19a923 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1038,11 +1038,21 @@ http.sslCert::\n \tover HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment\n \tvariable.\n \n+http.sslCertType::\n+\tFiletype for SSL certificate. Must be \"PEM\" (default), \"DER\", or\n+\t(if libcurl >= 7.13.0) \"P12\". Can be overridden by the\n+\t'GIT_SSL_CERT_TYPE' environment variable.\n+\n http.sslKey::\n \tFile containing the SSL private key when fetching or pushing\n \tover HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment\n \tvariable.\n \n+http.sslKeyType::\n+\tFiletype for SSL private key. Must be \"PEM\" (default), \"DER\", or\n+\t(if libcurl >= 7.13.0) \"P12\". Can be overridden by the\n+\t'GIT_SSL_CERT_TYPE' environment variable.\n+\n http.sslCAInfo::\n \tFile containing the certificates to verify the peer with when\n \tfetching or pushing over HTTPS. Can be overridden by the\ndiff --git a/http.c b/http.c\nindex b049948..5716e4e 100644\n--- a/http.c\n+++ b/http.c\n@@ -22,6 +22,8 @@ static int curl_ssl_verify = -1;\n static const char *ssl_cert;\n #if LIBCURL_VERSION_NUM >= 0x070903\n static const char *ssl_key;\n+static const char *ssl_cert_type;\n+static const char *ssl_key_type;\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n static const char *ssl_capath;\n@@ -129,6 +131,10 @@ static int http_options(const char *var, const char *value, void *cb)\n #if LIBCURL_VERSION_NUM >= 0x070903\n \tif (!strcmp(\"http.sslkey\", var))\n \t\treturn git_config_string(&ssl_key, var, value);\n+\tif (!strcmp(\"http.sslcerttype\", var))\n+\t\treturn git_config_string(&ssl_cert_type, var, value);\n+\tif (!strcmp(\"http.sslkeytype\", var))\n+\t\treturn git_config_string(&ssl_key_type, var, value);\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n \tif (!strcmp(\"http.sslcapath\", var))\n@@ -199,6 +205,10 @@ static CURL *get_curl_handle(void)\n #if LIBCURL_VERSION_NUM >= 0x070903\n \tif (ssl_key != NULL)\n \t\tcurl_easy_setopt(result, CURLOPT_SSLKEY, ssl_key);\n+\tif (ssl_cert_type != NULL)\n+\t\tcurl_easy_setopt(result, CURLOPT_SSLCERTTYPE, ssl_cert_type);\n+\tif (ssl_key_type != NULL)\n+\t\tcurl_easy_setopt(result, CURLOPT_SSLKEYTYPE, ssl_key_type);\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n \tif (ssl_capath != NULL)\n@@ -315,6 +325,8 @@ void http_init(struct remote *remote)\n \tset_from_env(&ssl_cert, \"GIT_SSL_CERT\");\n #if LIBCURL_VERSION_NUM >= 0x070903\n \tset_from_env(&ssl_key, \"GIT_SSL_KEY\");\n+\tset_from_env(&ssl_cert, \"GIT_SSL_CERT_TYPE\");\n+\tset_from_env(&ssl_key, \"GIT_SSL_KEY_TYPE\");\n #endif\n #if LIBCURL_VERSION_NUM >= 0x070908\n \tset_from_env(&ssl_capath, \"GIT_SSL_CAPATH\");\n-- \n1.6.3.2\n"},{"id":"116312","messageId":"7v63eyp10m.fsf@alter.siamese.dyndns.org","threadId":"19816","inReplyTo":"1245033541-15558-1-git-send-email-lodatom@gmail.com","subject":"Re: [PATCH 1/2] http.c: fix compiling with libcurl 7.9.2","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-15T04:35:37Z","receivedAt":"2009-06-15T04:35:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Lodato writes:\n\n> Change the minimimum required libcurl version for the http.sslKey option\n> to 7.9.3. Previously, preprocessor macros checked for >= 7.9.2, which\n> is incorrect because CURLOPT_SSLKEY was introduced in 7.9.3. This now\n> allows git to compile with libcurl 7.9.2.\n>\n> Signed-off-by: Mark Lodato \n> ---\n>\n> This patch series is independent of my other password prompting patch\n> series, and is based off 'next', which includes Tay Ray Chuan's recent\n> http changes.\n\nIn other words, this needs to be queued on top of rc/http-push series, and\nthe review process should involve the original author (Cc'ed).\n\nTay, comments?\n\n> Note that git still does not compile on libcurl before 7.9.1 or below,\n> since CURLOPT_FTP_USE_EPSV (http.c:236) is defined in libcurl 7.9.2.\n\nI think we didn't quite follow an old thread through, then. \n\nCf. http://thread.gmane.org/gmane.comp.version-control.git/113985/focus=114014\n\nBoth Mike's in the thread Cc'ed.\n\n> One question: In http.c, there are unnecessary #if LIBCURL_VERSION_NUM's\n> surrounding the global variable declarations, in http_options(), and in\n> http_init(). Is there a reason why these exist? If not, I think\n> removing them would make the code easier to read.\n\nYeah, as long as get_curl_handle() is still protected not to call\ncurl_easy_setopt() with an option that is unknown to the version of\nlibcURL, I think the config reader and variable declarations, and\ndefinitions can lose conditional compilation and it would make the overall\ncode easier to read.\n\nThanks.\n"},{"id":"116334","messageId":"be6fef0d0906150555l11df6dcbs16087554b08cc596@mail.gmail.com","threadId":"19816","inReplyTo":"7v63eyp10m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] http.c: fix compiling with libcurl 7.9.2","fromName":"Tay Ray Chuan","fromEmail":"rctay89@gmail.com","sentAt":"2009-06-15T12:55:08Z","receivedAt":"2009-06-15T12:55:08Z","isPatch":true,"sender":{"key":"rctay89@gmail.com","avatar":"https://avatars.githubusercontent.com/u/61553?v=4"},"body":"Hi,\n\nOn Mon, Jun 15, 2009 at 12:35 PM, Junio C Hamano wrote:\n> In other words, this needs to be queued on top of rc/http-push series, and\n> the review process should involve the original author (Cc'ed).\n>\n> Tay, comments?\n\nThanks for the heads-up. I don't have anything to add, since Mark's\nwork doesn't really affect mine (http fetching logic).\n\n-- \nCheers,\nRay Chuan\n"},{"id":"116349","messageId":"alpine.OSX.2.00.0906151927010.816@xor.localnet","threadId":"19816","inReplyTo":"1245033541-15558-2-git-send-email-lodatom@gmail.com","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Karsten Weiss","fromEmail":"knweiss@gmx.de","sentAt":"2009-06-15T17:43:52Z","receivedAt":"2009-06-15T17:43:52Z","isPatch":true,"sender":{"key":"knweiss@gmx.de","avatar":null},"body":"Hi Mark!\n\nOn Sun, 14 Jun 2009, Mark Lodato wrote:\n\n> Add two new configuration variables, http.sslCertType and\n> http.sslKeyType, which tell libcurl the filetype for the SSL client\n> certificate and private key, respectively. The main benefit is to allow\n> PKCS12 certificates for users with libcurl >= 7.13.0.\n\nThis is interesting. Thanks for working on that!\n\n(However, it's a similar issue like the question whether the private key \nis encrypted or not: Usability would be better if the certificate type \ncould be determined automatically (without having to violate the \nlayering)).\n\n>> +http.sslKeyType::\n> +\tFiletype for SSL private key. Must be \"PEM\" (default), \"DER\", or\n> +\t(if libcurl >= 7.13.0) \"P12\". Can be overridden by the\n> +\t'GIT_SSL_CERT_TYPE' environment variable.\n ^^^^\n KEY\n\nRegards,\nKarsten\n"},{"id":"116371","messageId":"ca433830906151755t783fbf98k3fd09e4bdd6781e8@mail.gmail.com","threadId":"19816","inReplyTo":"alpine.OSX.2.00.0906151927010.816@xor.localnet","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-16T00:55:10Z","receivedAt":"2009-06-16T00:55:10Z","isPatch":true,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Mon, Jun 15, 2009 at 1:43 PM, Karsten Weiss wrote:\n> Hi Mark!\n>\n> On Sun, 14 Jun 2009, Mark Lodato wrote:\n>\n>> Add two new configuration variables, http.sslCertType and\n>> http.sslKeyType, which tell libcurl the filetype for the SSL client\n>> certificate and private key, respectively.  The main benefit is to allow\n>> PKCS12 certificates for users with libcurl >= 7.13.0.\n>\n> This is interesting. Thanks for working on that!\n>\n> (However, it's a similar issue like the question whether the private key is\n> encrypted or not: Usability would be better if the certificate type could be\n> determined automatically (without having to violate the layering)).\n\nJust as with determining if the certificate is password protected, it\nis equally difficult to tell what type of file it is without calling\nOpenSSL directly.\n\nThis brings up a good point: Should we (I) try to implement (client\ncertificate) usability features in git to work around deficiencies in\nlibcurl, or should we (I) write patches to fix/enhance libcurl\ndirectly? The latter would be much easier (though I could be wrong)\nand would benefit other programs using libcurl, but would require\nusers to upgrade libcurl to get these new features, and of course\nwould rely on the libcurl developers accepting the patches. I am\nwilling to do either, but I think the libcurl route would be better.\nAny thoughts?\n\n\nAnyway, to implement this in git, the algorithm would be something like:\n\nfor password in [None, \"\", prompt()]:\n for type in [\"PEM\", \"DER\", (if libcurl >= 7.13.0) \"P12\"]:\n try to make a connection with password and type\n if not certificate error:\n return success\nelse:\n return failure\n\nThis is much more difficult than it may at first appear. I'm sure it\ncan be done, but it will take a while to get it right.\n\n\nMark\n"},{"id":"116374","messageId":"ca433830906151756s7c3f8a1cge360a9d7a08562d1@mail.gmail.com","threadId":"19816","inReplyTo":"alpine.OSX.2.00.0906151927010.816@xor.localnet","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2009-06-16T00:56:25Z","receivedAt":"2009-06-16T00:56:25Z","isPatch":true,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Mon, Jun 15, 2009 at 1:43 PM, Karsten Weiss wrote:\n>>> +http.sslKeyType::\n>>\n>> +       Filetype for SSL private key.  Must be \"PEM\" (default), \"DER\", or\n>> +       (if libcurl >= 7.13.0) \"P12\".  Can be overridden by the\n>> +       'GIT_SSL_CERT_TYPE' environment variable.\n>\n>                 ^^^^\n>                 KEY\n\nWhoops - thanks. Sorry for that typo.\n\nMark\n"},{"id":"116384","messageId":"7vprd4g1rv.fsf@alter.siamese.dyndns.org","threadId":"19816","inReplyTo":"ca433830906151755t783fbf98k3fd09e4bdd6781e8@mail.gmail.com","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-16T05:56:20Z","receivedAt":"2009-06-16T05:56:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mark Lodato writes:\n\n> This brings up a good point: Should we (I) try to implement (client\n> certificate) usability features in git to work around deficiencies in\n> libcurl, or should we (I) write patches to fix/enhance libcurl\n> directly? The latter would be much easier (though I could be wrong)\n> and would benefit other programs using libcurl, but would require\n> users to upgrade libcurl to get these new features, and of course\n> would rely on the libcurl developers accepting the patches. I am\n> willing to do either, but I think the libcurl route would be better.\n> Any thoughts?\n\nI agree that would be a better approach in the longer term. There is no\npoint in many projects that use libcURL reinventing the wheel that could\nbe in the shared library.\n\nPerhaps we could do both ;-).\n\nThat is, (1) give libcURL a way to allow callers ask if the key/cert is\nencrypted, and then (2) on git side we only add code to ask libcURL using\nthat interface _only if and when available_; otherwise we do not even try\nto bypass layers but just ask the user to tell us via configuration (or\ncommand line).\n"},{"id":"116389","messageId":"7vd494eku3.fsf@alter.siamese.dyndns.org","threadId":"19816","inReplyTo":"7vprd4g1rv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-16T06:47:32Z","receivedAt":"2009-06-16T06:47:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I agree that would be a better approach in the longer term. There is no\n> point in many projects that use libcURL reinventing the wheel that could\n> be in the shared library.\n>\n> Perhaps we could do both ;-).\n>\n> That is, (1) give libcURL a way to allow callers ask if the key/cert is\n> encrypted, and then (2) on git side we only add code to ask libcURL using\n> that interface _only if and when available_; otherwise we do not even try\n> to bypass layers but just ask the user to tell us via configuration (or\n> command line).\n\nI guess I somewhat misread what you were saying (and I seem to be doing\nthis more often recently---I should slow down).\n\nFor key/cert type, the current cURL interface you used expects the caller\nto say \"I am giving you the name of the cert file, and the file is of this\ntype\". I think the usability enhancement would be something like \"Here is\nthe cert file; it should be one of the types supported by you (I do not\nknow nor care what exact type it is, but the end user tells me that you\nshould be able to use it). Please do whatever necessary with it.\"\n\nFor key/cert passphrase, the current cURL interface we use expects the\ncaller to give a string value via setopt. I wonder if there already is an\nexisting interface to give a callback function that is responsible for\ndoing user interaction and return a string? The best case would be to use\nsuch an interface if available; otherwise, it would be good to add such an\ninterface to libcURL for us and other people to use.\n\nI imagine the user would look something like this:\n\n\tstatic char *ssl_cert_password;\n\tstatic const char *callback(const char *hint, int trial, void *cb)\n {\n\t\tchar buf[256];\n if (!trial)\n \treturn ssl_cert_password ? ssl_cert_password : \"\";\n\t\tif (5 < trial) {\n\t\t\terror(\"Wrong passphrase. Giving up...\");\n\t\t\treturn NULL;\n }\n\t\tsprintf(buf, \"Passphrase to unlock %s: \", hint);\n ssl_cert_password = getpass(buf);\n return ssl_cert_password;\n }\n\nwhere\n\n (1) The calling program (i.e. us) sets the address of the callback\n function via curl_easy_setopt() when registering a key/cert file;\n\n (2) When libcURL needs to unlock the key/cert file and sees such a\n callback registered, it is called with \"hint\" (probably the filename\n of the key/cert file it is trying to unlock), trial count (initially\n zero) and an arbitrary callback data the program passed when it\n registered the callback in the step (1). The callback is expected to\n return a passphrase string.\n\n (3) The callback can return an empty string to tell the library to try\n using an empty passphrase (aka unencrypted keyfile).\n\n (4) If the returned string does not unlock the key/cert file\n successfully, libcURL is expected to call the callback with the same\n hint/cb but trial count incremented. The callback can return NULL to\n signal that the user/program gave up.\n\nThat way, we wouldn't even have to make a \"trial connection\" we earlier\ndiscussed. The first request to make a connection we make into the\nlibrary can also serve as the \"trial connection\".\n"},{"id":"116440","messageId":"alpine.OSX.2.00.0906162137100.80034@xor.localnet","threadId":"19816","inReplyTo":"ca433830906151755t783fbf98k3fd09e4bdd6781e8@mail.gmail.com","subject":"Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType","fromName":"Karsten Weiss","fromEmail":"knweiss@gmx.de","sentAt":"2009-06-16T20:07:34Z","receivedAt":"2009-06-16T20:07:34Z","isPatch":true,"sender":{"key":"knweiss@gmx.de","avatar":null},"body":"On Mon, 15 Jun 2009, Mark Lodato wrote:\n\n>> (However, it's a similar issue like the question whether the private key is\n>> encrypted or not: Usability would be better if the certificate type could be\n>> determined automatically (without having to violate the layering)).\n>\n> Just as with determining if the certificate is password protected, it\n> is equally difficult to tell what type of file it is without calling\n> OpenSSL directly.\n\nHm, thinking about the encryption case: Maybe I'm missing something but \nwouldn't it be enough to simply peek at the key file and look for the \nstring \"ENCRYPTED\" in a header like this?\n\n-----BEGIN RSA PRIVATE KEY-----\nProc-Type: 4,ENCRYPTED\n\nI.e. a simple, temporary solution that does not depend on OpenSSL to \nprevent the introduction of the new http.sslCertNoPass flag?\n\n(But now that you've also created patches for PKCS12 support this might \nnot be feasible anymore?)\n\n> This brings up a good point: Should we (I) try to implement (client\n> certificate) usability features in git to work around deficiencies in\n> libcurl, or should we (I) write patches to fix/enhance libcurl\n> directly? The latter would be much easier (though I could be wrong)\n> and would benefit other programs using libcurl, but would require\n> users to upgrade libcurl to get these new features, and of course\n> would rely on the libcurl developers accepting the patches. I am\n> willing to do either, but I think the libcurl route would be better.\n> Any thoughts?\n\n(As a git user without libcurl insights) I think that such query functions \nabout private keys (Is it encrypted?) or certificates (What type is it?) \nwould make sense and belong into libcurl. (And it would be great if these \nqueries could be answered *without* performing actual trial network \nconnections just by looking into the respective key/certificate files.)\n\nKarsten\n"},{"id":"116582","messageId":"e2b179460906180926h47070d2aw4a50e3a8547cfb61@mail.gmail.com","threadId":"19816","inReplyTo":"7v63eyp10m.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] http.c: fix compiling with libcurl 7.9.2","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-06-18T16:26:11Z","receivedAt":"2009-06-18T16:26:11Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/6/15 Junio C Hamano \n>\n> Mark Lodato writes:\n> > Note that git still does not compile on libcurl before 7.9.1 or below,\n> > since CURLOPT_FTP_USE_EPSV (http.c:236) is defined in libcurl 7.9.2.\n>\n> I think we didn't quite follow an old thread through, then.\n>\n> Cf. http://thread.gmane.org/gmane.comp.version-control.git/113985/focus=114014\n>\n> Both Mike's in the thread Cc'ed.\n\nYep, apologies for having dropped the ball on this. I had got back to\nit but parked it again while Ray Chaun's series was in flight.\n\nWill be offline for a couple of weeks around solstice / Glastonbury\nbut able to pick it up again after that if no-one beats me to it. I've\nnoted Daniel's point below also:\n\n2009/6/12 Daniel Stenberg :\n> On Thu, 11 Jun 2009, Junio C Hamano wrote:\n>\n>> #if !defined(CURLOPT_KEYPASSWD)\n>> # if defined(CURLOPT_SSLKEYPASSWD)\n>> # define CURLOPT_KEYTPASSWD CURLOPT_SSLKEYPASSWD\n>> # elif defined(CURLOPT_SSLCERTPASSWD\n>> # define CURLOPT_KEYTPASSWD CURLOPT_SSLCERTPASSWD\n>> # endif\n>> #endif\n>\n> Just note that these CURLOPT_* symbols provided by libcurl are enums, not\n> defines, so unfortunately you can't do it this exact #ifdef way.\n\nMike\n"}]}