{"thread":{"id":"35665","subject":"[PATCH] send-email: If the ca path is not specified, use the defaults","startedAt":"2014-01-15T17:31:11Z","lastAt":"2014-01-27T16:02:31Z","messageCount":11,"participants":["Igor Gnatenko","Junio C Hamano","Ruben Kerkhof","Jonathan Nieder","Kyle J. McKay","Ramkumar Ramachandra"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"233163","messageId":"1389807071-26746-1-git-send-email-i.gnatenko.brain@gmail.com","threadId":"35665","inReplyTo":null,"subject":"[PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Igor Gnatenko","fromEmail":"i.gnatenko.brain@gmail.com","sentAt":"2014-01-15T17:31:11Z","receivedAt":"2014-01-15T17:31:11Z","isPatch":true,"sender":{"key":"i.gnatenko.brain@gmail.com","avatar":null},"body":"From: Ruben Kerkhof \n\nI use gmail for sending patches.\nIf I have the following defined in my ~/.gitconfig:\n[sendemail]\n\tsmtpencryption = tls\n\tsmtpserver = smtp.gmail.com\n\tsmtpuser = ruben@rubenkerkhof.com\n\tsmtpserverport = 587\n\nand try to send a patch, this fails with:\nSTARTTLS failed! SSL connect attempt failed with unknown error\nerror:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate\nverify failed at /usr/libexec/git-core/git-send-email line 1236.\n\nTested-by: Igor Gnatenko \nSigned-off-by: Ruben Kerkhof \nReference: https://bugzilla.redhat.com/show_bug.cgi?id=1043194\n---\n git-send-email.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 3782c3b..689944f 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1095,7 +1095,8 @@ sub ssl_verify_params {\n \t}\n \n \tif (!defined $smtp_ssl_cert_path) {\n-\t\t$smtp_ssl_cert_path = \"/etc/ssl/certs\";\n+\t\t# use the OpenSSL defaults\n+\t\treturn (SSL_verify_mode => SSL_VERIFY_PEER());\n \t}\n \n \tif ($smtp_ssl_cert_path eq \"\") {\n-- \n1.8.4.2\n"},{"id":"233165","messageId":"xmqqa9ex2gi6.fsf@gitster.dls.corp.google.com","threadId":"35665","inReplyTo":"1389807071-26746-1-git-send-email-i.gnatenko.brain@gmail.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-15T19:26:41Z","receivedAt":"2014-01-15T19:26:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Igor Gnatenko writes:\n\n> From: Ruben Kerkhof \n>\n> I use gmail for sending patches.\n> If I have the following defined in my ~/.gitconfig:\n> [sendemail]\n> \tsmtpencryption = tls\n> \tsmtpserver = smtp.gmail.com\n> \tsmtpuser = ruben@rubenkerkhof.com\n> \tsmtpserverport = 587\n>\n> and try to send a patch, this fails with:\n> STARTTLS failed! SSL connect attempt failed with unknown error\n> error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate\n> verify failed at /usr/libexec/git-core/git-send-email line 1236.\n\n... because? Is it because the cert_path on your platform is\ndifferent from /etc/ssl/certs? What platform was this anyway?\n\nI see in the original discussion in your bugzilla entry that\n\"/etc/ssl/certs/\" _is_ your ssl cert directory, but I wonder why\nthen this part of the existing codepath does not work for you:\n\n\tif (!defined $smtp_ssl_cert_path) {\n\t\t$smtp_ssl_cert_path = \"/etc/ssl/certs\";\n\t}\n\n\tif ($smtp_ssl_cert_path eq \"\") {\n\t\treturn (SSL_verify_mode => SSL_VERIFY_NONE());\n\t} elsif (-d $smtp_ssl_cert_path) {\n\t\treturn (SSL_verify_mode => SSL_VERIFY_PEER(),\n\t\t\tSSL_ca_path => $smtp_ssl_cert_path);\n\t} elsif (-f $smtp_ssl_cert_path) {\n\t\treturn (SSL_verify_mode => SSL_VERIFY_PEER(),\n\t\t\tSSL_ca_file => $smtp_ssl_cert_path);\n\t} else ...\n\nWe set cert_path to \"/etc/ssl/certs\" and return SSL_VERIFY_PEER() as\nthe SSL_verify_mode, and also return that directory as SSL_ca_path,\nwhich means the callsites of the ssl_verify_params sub, which are\nNet::SMTP:SSL->start_SSL() or IO::Socket::SSL::set_client_defaults(),\nwill be told with SSL_ca_path (not SSL_ca_file) that\n\"/etc/ssl/certs\" is the directory to find the certificates in.\n\nNow, http://search.cpan.org/~sullr/IO-Socket-SSL-1.964/lib/IO/Socket/SSL.pm\nsays:\n\n SSL_ca_file | SSL_ca_path\n\n Usually you want to verify that the peer certificate has been\n signed by a trusted certificate authority. In this case you\n should use this option to specify the file (SSL_ca_file) or\n directory (SSL_ca_path) containing the certificate(s) of the\n trusted certificate authorities.\n\nSo I have to wonder why isn't this working. Without knowing why\nusing SSL_ca_path for the certificate directory is not working on\nyour platform, the patch looks more like a band-aid that works\naround an undiagnosed malfunction of IO::Socket::SSL on your\nplatform than a real solution to the breakage, no?\n\nPuzzled...\n\nBy the way, please do not tell the readers of proposed log message\nto refer to your custom \"Reference:\" footer to answer the\n\"... because?\" question at the beginning of this message. Your\nproposed log message should have allowed anybody who comments on\nyour patch to make the above observation without referring to\nexternal website.\n\nHaving said all that.\n\nDoes this patch affect people on other distros, who never set the\ncert_path in their configuration and have been relying on the\nhardwired default? If so in what way?\n\nMy knee-jerk answer to that question is that it would negatively\naffect folks only if their platform does have the certs in\n/etc/ssl/certs/, but their Perl IO::Socket::SSL somehow defaults to\na wrong location, which is already a broken installation. In that\nsense, I suspect that the potential downside of this patch may be\nsmall, but I'd prefer to see evidence that the patch author thought\nthrough ramifications of the change in the proposed log message ;-)\n\nAlso, if the above observation is correct, i.e. we are calling\nIO::Socket::SSL with SSL_ca_path set to a correct directory but\nsomehow your platform is misbehaving and not detecting it as a\nproper SSL_ca_path, then it could be argued that the code before\nthis patch catered people on platforms with one class of breakage,\nnamely \"IO::Socket::SSL does not work with default configuration\nwithout SSL_ca_file nor SSL_ca_path\", and the code with this patch\ncaters people on platforms with another class of breakage, namely\n\"IO::Socket::SSL does not work when told with SSL_ca_path where the\ncertificate directory is\" (or it could be \"/etc/ssl/certs is a\ndirectory that ought to be usable as SSL_ca_path, but it lacks\nnecessary hash symlinks\"). Sort of like robbing Peter to pay Paul,\nwhich is not very nice in principle.\n\n> Tested-by: Igor Gnatenko \n> Signed-off-by: Ruben Kerkhof \n> Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1043194\n> ---\n> git-send-email.perl | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 3782c3b..689944f 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -1095,7 +1095,8 @@ sub ssl_verify_params {\n> \t}\n> \n> \tif (!defined $smtp_ssl_cert_path) {\n> -\t\t$smtp_ssl_cert_path = \"/etc/ssl/certs\";\n> +\t\t# use the OpenSSL defaults\n> +\t\treturn (SSL_verify_mode => SSL_VERIFY_PEER());\n> \t}\n> \n> \tif ($smtp_ssl_cert_path eq \"\") {\n"},{"id":"233170","messageId":"xmqqob3d0w7g.fsf@gitster.dls.corp.google.com","threadId":"35665","inReplyTo":"7AD1C6ED-6177-415D-B342-D1FEA9F810B4@rubenkerkhof.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-15T21:30:27Z","receivedAt":"2014-01-15T21:30:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ruben Kerkhof writes:\n\n>> ... because? Is it because the cert_path on your platform is\n>> different from /etc/ssl/certs? What platform was this anyway?\n>\n> This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64, perl-IO-Socket-SSL-1.962-1.fc21.noarch\n>> \n>> I see in the original discussion in your bugzilla entry that\n>> \"/etc/ssl/certs/\" _is_ your ssl cert directory, but I wonder why\n>> then this part of the existing codepath does not work for you:\n>\n> Actually, it's not a directory but a symlink to a directory:\n>\n> [ruben@vm ~]$ ls -l /etc/ssl/certs\n> lrwxrwxrwx. 1 root root 16 Jan 11 12:04 /etc/ssl/certs -> ../pki/tls/certs\n>\n> Just to rule that out I set smtpsslcertpath = /etc/pki/tls/certs,\n> but that doesn't work either.\n\nYeah, I suspect as much, as \"-d\" test would dereference symlinks and\nwould see /etc/ssl/certs is a symlink pointing at a directory.\n\n> ... I posted the patch to Fedora's bugzilla, since this was\n> biting me on Fedora, and Igor took the liberty to forward it. Not\n> that I mind of course, but please don't take this patch as a\n> proper fix. I don't pretend to fully understand the code and the\n> implications, much less the impact on other platforms.\n\nThat is fine, and thanks for starting discussion for a proper fix\n(the \"thanks\" go to both of you).\n\n>> Also, if the above observation is correct, i.e. we are calling\n>> IO::Socket::SSL with SSL_ca_path set to a correct directory but\n>> somehow your platform is misbehaving and not detecting it as a\n>> proper SSL_ca_path, then it could be argued that the code before\n>> this patch catered people on platforms with one class of breakage,\n>> namely \"IO::Socket::SSL does not work with default configuration\n>> without SSL_ca_file nor SSL_ca_path\", and the code with this patch\n>> caters people on platforms with another class of breakage, namely\n>> \"IO::Socket::SSL does not work when told with SSL_ca_path where the\n>> certificate directory is\" (or it could be \"/etc/ssl/certs is a\n>> directory that ought to be usable as SSL_ca_path, but it lacks\n>> necessary hash symlinks\"). Sort of like robbing Peter to pay Paul,\n>> which is not very nice in principle.\n>\n> I suspect that's exactly the case,...\n\nActually, there is another possibility. Perhaps on your system,\neven though the current code thinks /etc/ssl/certs/ is usable as\nSSL_ca_path, the directory is not meant to be usable as such, and\nthe default OpenSSL uses the equivalent of SSL_ca_file and uses the\nsingle certificate bundle file without consulting other stuff in the\ndirectory.\n\nAnd that is not a broken installation at all, which is sort of\nconsistent with your observation here: \n\n> ...\n> As a last check, I set smtpsslcertpath = /etc/pki/tls/cert.pem in\n> ~/.gitconfig and git-send-email works fine now.\n\nWhich would mean that the existing code, by blindly defaulting to\n/etc/ssl/certs/ and misdiagnosing that the directory is meant to be\nused as SSL_ca_path, breaks a set-up that otherwise _should_ work.\n\nI see that the original change that introduced the defaulting to\n/etc/ssl/certs/, which is 35035bbf (send-email: be explicit with SSL\ncertificate verification, 2013-07-18), primarily wanted to avoid\nletting Net::SMTP::SSL defaulting to no verification and causing it\nto emit warnings of the use of the insecure default. And I think\nthe same outcome will result with your patch. By default, we still\ninsist on using SSL_VERIFY_PEER(), not SSL_VERIFY_NONE(), which\nwould avoid defaulting to insecure communication and triggering the\nwarning. The way to disable the security by setting ssl_cert_path\nto an empty string is unchanged.\n\nRam (who did 35035bbf), with the patch from Ruben in the thread, do\nyou get either the warning or SSL failure? Conceptually, the\nresulting code is much better, I think, without blindly defaulting\n/etc/ssl/certs and instead of relying on the underlying platform\njust working out of the box with its own default, and I would be\nhappy if we can apply the change without regression to existing\nusers.\n"},{"id":"233171","messageId":"5AD43B9B-A9E3-48CA-919C-4AB54F122F92@rubenkerkhof.com","threadId":"35665","inReplyTo":"xmqqob3d0w7g.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Ruben Kerkhof","fromEmail":"ruben@rubenkerkhof.com","sentAt":"2014-01-15T21:50:00Z","receivedAt":"2014-01-15T21:50:00Z","isPatch":true,"sender":{"key":"ruben@rubenkerkhof.com","avatar":null},"body":"\nOn 15 jan. 2014, at 22:30, Junio C Hamano wrote:\n\n> Ruben Kerkhof writes:\n> \n>>> ... because? Is it because the cert_path on your platform is\n>>> different from /etc/ssl/certs? What platform was this anyway?\n>> \n>> This is Fedora rawhide, git-1.8.5.2-1.fc21.x86_64, perl-IO-Socket-SSL-1.962-1.fc21.noarch\n>>> \n>>> I see in the original discussion in your bugzilla entry that\n>>> \"/etc/ssl/certs/\" _is_ your ssl cert directory, but I wonder why\n>>> then this part of the existing codepath does not work for you:\n>> \n>> Actually, it's not a directory but a symlink to a directory:\n>> \n>> [ruben@vm ~]$ ls -l /etc/ssl/certs\n>> lrwxrwxrwx. 1 root root 16 Jan 11 12:04 /etc/ssl/certs -> ../pki/tls/certs\n>> \n>> Just to rule that out I set smtpsslcertpath = /etc/pki/tls/certs,\n>> but that doesn't work either.\n> \n> Yeah, I suspect as much, as \"-d\" test would dereference symlinks and\n> would see /etc/ssl/certs is a symlink pointing at a directory.\n> \n>> ... I posted the patch to Fedora's bugzilla, since this was\n>> biting me on Fedora, and Igor took the liberty to forward it. Not\n>> that I mind of course, but please don't take this patch as a\n>> proper fix. I don't pretend to fully understand the code and the\n>> implications, much less the impact on other platforms.\n> \n> That is fine, and thanks for starting discussion for a proper fix\n> (the \"thanks\" go to both of you).\n> \n>>> Also, if the above observation is correct, i.e. we are calling\n>>> IO::Socket::SSL with SSL_ca_path set to a correct directory but\n>>> somehow your platform is misbehaving and not detecting it as a\n>>> proper SSL_ca_path, then it could be argued that the code before\n>>> this patch catered people on platforms with one class of breakage,\n>>> namely \"IO::Socket::SSL does not work with default configuration\n>>> without SSL_ca_file nor SSL_ca_path\", and the code with this patch\n>>> caters people on platforms with another class of breakage, namely\n>>> \"IO::Socket::SSL does not work when told with SSL_ca_path where the\n>>> certificate directory is\" (or it could be \"/etc/ssl/certs is a\n>>> directory that ought to be usable as SSL_ca_path, but it lacks\n>>> necessary hash symlinks\"). Sort of like robbing Peter to pay Paul,\n>>> which is not very nice in principle.\n>> \n>> I suspect that's exactly the case,...\n> \n> Actually, there is another possibility. Perhaps on your system,\n> even though the current code thinks /etc/ssl/certs/ is usable as\n> SSL_ca_path, the directory is not meant to be usable as such, and\n> the default OpenSSL uses the equivalent of SSL_ca_file and uses the\n> single certificate bundle file without consulting other stuff in the\n> directory.\n> \n> And that is not a broken installation at all, which is sort of\n> consistent with your observation here: \n> \n>> ...\n>> As a last check, I set smtpsslcertpath = /etc/pki/tls/cert.pem in\n>> ~/.gitconfig and git-send-email works fine now.\n> \n> Which would mean that the existing code, by blindly defaulting to\n> /etc/ssl/certs/ and misdiagnosing that the directory is meant to be\n> used as SSL_ca_path, breaks a set-up that otherwise _should_ work.\n\nExactly. IO::Socket::SSL calls Net::SSLeay::CTX_load_verify_locations( $ctx, $arg_hash->{SSL_ca_file} || '',$arg_hash->{SSL_ca_path} || ''),\nwhich in turn calls OpenSSL's SSL_CTX_load_verify_locations\n\nAccording to the comments at http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html, the CApath should be a directory with hashes pointing to\nto certs, which is not the case in Fedora.\n> \n> I see that the original change that introduced the defaulting to\n> /etc/ssl/certs/, which is 35035bbf (send-email: be explicit with SSL\n> certificate verification, 2013-07-18), primarily wanted to avoid\n> letting Net::SMTP::SSL defaulting to no verification and causing it\n> to emit warnings of the use of the insecure default. And I think\n> the same outcome will result with your patch. By default, we still\n> insist on using SSL_VERIFY_PEER(), not SSL_VERIFY_NONE(), which\n> would avoid defaulting to insecure communication and triggering the\n> warning. The way to disable the security by setting ssl_cert_path\n> to an empty string is unchanged.\n> \n> Ram (who did 35035bbf), with the patch from Ruben in the thread, do\n> you get either the warning or SSL failure? Conceptually, the\n> resulting code is much better, I think, without blindly defaulting\n> /etc/ssl/certs and instead of relying on the underlying platform\n> just working out of the box with its own default, and I would be\n> happy if we can apply the change without regression to existing\n> users.\n\n\n/etc/pki/tls/cert.pem is a symlink to the Mozilla CA bundle,\n/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem, which as far as I can tell is the one that should be used for this distro.\n\nKind regards,\n\nRuben"},{"id":"233172","messageId":"20140115215024.GM18964@google.com","threadId":"35665","inReplyTo":"xmqqob3d0w7g.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-01-15T21:50:24Z","receivedAt":"2014-01-15T21:50:24Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Ruben Kerkhof writes:\n\n>> As a last check, I set smtpsslcertpath = /etc/pki/tls/cert.pem in\n>> ~/.gitconfig and git-send-email works fine now.\n>\n> Which would mean that the existing code, by blindly defaulting to\n> /etc/ssl/certs/ and misdiagnosing that the directory is meant to be\n> used as SSL_ca_path, breaks a set-up that otherwise _should_ work.\n[...]\n> Ram (who did 35035bbf), with the patch from Ruben in the thread, do\n> you get either the warning or SSL failure? Conceptually, the\n> resulting code is much better, I think, without blindly defaulting\n> /etc/ssl/certs and instead of relying on the underlying platform\n> just working out of the box with its own default,\n\nFWIW this should help on Mac OS X, too. Folks using git on mac\nat $DAYJOB have been using the workaround described at\nhttp://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher\nso I forgot to report it. :/\n\nThanks,\nJonathan\n"},{"id":"233237","messageId":"xmqqppnry0p9.fsf@gitster.dls.corp.google.com","threadId":"35665","inReplyTo":"20140115215024.GM18964@google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-16T23:19:14Z","receivedAt":"2014-01-16T23:19:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> FWIW this should help on Mac OS X, too. Folks using git on mac\n> at $DAYJOB have been using the workaround described at\n> http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher\n> so I forgot to report it. :/\n\nHmph, is that the same issue, though? That page seems to suggest\nusing an empty ca file that does not have any useful information as\na workaround. The issue Fedora folks saw is that we see a directory\n/etc/ssl/certs exist on the system, and blindly attempt to use it as\nSSL_ca_path when the directory is not suitable to be used as such.\n\nIn any case, I tried to summarize the discussion in the updated log\nmessage. I wanted to say \"does not\" but stopped at \"should not\" in\nthe last paragraph for now. Maybe Ram can say something before we\nmerge it to 'next'.\n\nThe patch in the meantime will be queued on 'pu'.\n\n-- >8 --\nFrom: Ruben Kerkhof \nDate: Wed, 15 Jan 2014 21:31:11 +0400\nSubject: [PATCH] send-email: /etc/ssl/certs/ directory may not be usable as ca_path\n\nWhen sending patches on Fedora rawhide with\ngit-1.8.5.2-1.fc21.x86_64 and perl-IO-Socket-SSL-1.962-1.fc21.noarch,\nwith the following\n\n [sendemail]\n\t smtpencryption = tls\n\t smtpserver = smtp.gmail.com\n\t smtpuser = ruben@rubenkerkhof.com\n\t smtpserverport = 587\n\ngit-send-email fails with:\n\n STARTTLS failed! SSL connect attempt failed with unknown error\n error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate\n verify failed at /usr/libexec/git-core/git-send-email line 1236.\n\nThe current code detects the presence of /etc/ssl/certs directory\n(it actually is a symlink to another directory, but that does not\nmatter) and uses SSL_ca_path to point at it when initializing the\nconnection with IO::Socket::SSL or Net::SMTP::SSL. However, on the\nsaid platform, it seems that this directory is not designed to be\nused as SSL_ca_path. Using a single file inside that directory\n(cert.pem, which is a Mozilla CA bundle) with SSL_ca_file does work,\nand also not specifying any SSL_ca_file/SSL_ca_path (and letting the\nlibrary use its own default) and asking for peer verification does\nwork.\n\nBy removing the code that blindly defaults $smtp_ssl_cert_path to\n\"/etc/ssl/certs\", we can prevent the codepath that treats any\ndirectory specified with that variable as usable for SSL_ca_path\nfrom incorrectly triggering.\n\nThis change could introduce a regression for people on a platform\nwhose certificate directory is /etc/ssl/certs but its IO::Socket:SSL\nsomehow fails to use it as SSL_ca_path without being told. Using\n/etc/ssl/certs directory as SSL_ca_path by default like the current\ncode does would have been hiding such a broken installation without\nits user needing to do anything. These users can still work around\nsuch a platform bug by setting the configuration variable explicitly\nto point at /etc/ssl/certs.\n\nThis change should not negate what 35035bbf (send-email: be explicit\nwith SSL certificate verification, 2013-07-18), which was the\noriginal change that introduced the defaulting to /etc/ssl/certs/,\nattempted to do, which is to make sure we do not communicate over\ninsecure connection by default, triggering warning from the library.\n\nCf. https://bugzilla.redhat.com/show_bug.cgi?id=1043194\n\nTested-by: Igor Gnatenko \nSigned-off-by: Ruben Kerkhof \nSigned-off-by: Junio C Hamano \n---\n git-send-email.perl | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 3782c3b..689944f 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -1095,7 +1095,8 @@ sub ssl_verify_params {\n \t}\n \n \tif (!defined $smtp_ssl_cert_path) {\n-\t\t$smtp_ssl_cert_path = \"/etc/ssl/certs\";\n+\t\t# use the OpenSSL defaults\n+\t\treturn (SSL_verify_mode => SSL_VERIFY_PEER());\n \t}\n \n \tif ($smtp_ssl_cert_path eq \"\") {\n-- \n1.8.5.3-493-gb139ac2\n"},{"id":"233262","messageId":"E036CD5E-69B1-4ABD-957B-8E31D410A897@gmail.com","threadId":"35665","inReplyTo":"xmqqppnry0p9.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-01-17T04:21:32Z","receivedAt":"2014-01-17T04:21:32Z","isPatch":true,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jan 16, 2014, at 15:19, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> FWIW this should help on Mac OS X, too. Folks using git on mac\n>> at $DAYJOB have been using the workaround described at\n>> http://mercurial.selenic.com/wiki/CACertificates#Mac_OS_X_10.6_and_higher\n>> so I forgot to report it. :/\n>\n> Hmph, is that the same issue, though? That page seems to suggest\n> using an empty ca file that does not have any useful information as\n> a workaround.\n\nI had written up this draft email that describes the situation on OS X \nand decided it might not be exactly on topic and wasn't going to send \nit, but, since you asked... ;)\n\nOpenSSL's default location can be found with:\n\n openssl version -d\n\nOn my Ubuntu system I get this:\n\n $ openssl version -d\n OPENSSLDIR: \"/usr/lib/ssl\"\n\nThen if I look in there like so:\n\n $ ls -l /usr/lib/ssl\n total 8\n lrwxrwxrwx 1 root root 14 certs -> /etc/ssl/certs\n drwxr-xr-x 2 root root 4096 engines\n drwxr-xr-x 2 root root 4096 misc\n lrwxrwxrwx 1 root root 20 openssl.cnf -> /etc/ssl/openssl.cnf\n lrwxrwxrwx 1 root root 16 private -> /etc/ssl/private\n\nAnd that's how it ends up using /etc/ssl/certs. From the \nSSL_CTX_load_verify_locations man page:\n\n \"When looking up CA certificates, the OpenSSL library will first \nsearch the certificates in CAfile, then those in CApath.\"\n\nThe default CAfile is \"cert.pem\" and the default CApath is \"certs\" \nboth located in the openssl version -d directory. See the crypto/ \ncryptlib.h header [1].\n\nOn my OS X platform depending on which version of OpenSSL I'm using, \nthe OPENSSLDIR path would be one of these:\n\n /System/Library/OpenSSL\n /opt/local/etc/openssl\n\nAnd neither of those uses a \"certs\" directory, they both use a \n\"cert.pem\" bundle instead:\n\n $ ls -l /System/Library/OpenSSL\n total 32\n lrwxrwxrwx 1 root wheel 42 cert.pem -> ../../../usr/share/curl/ \ncurl-ca-bundle.crt\n drwxr-xr-x 2 root wheel 68 certs\n drwxr-xr-x 8 root wheel 272 misc\n -rw-r--r-- 1 root wheel 9381 openssl.cnf\n drwxr-xr-x 2 root wheel 68 private\n # the certs directory is empty\n\n $ ls -l /opt/local/etc/openssl\n total 32\n lrwxrwxrwx 1 root admin 35 cert.pem@ -> ../../share/curl/curl- \nca-bundle.crt\n drwxr-xr-x 9 root admin 306 misc/\n -rw-r--r-- 1 root admin 10835 openssl.cnf\n\nNotice neither of those refers to /etc/ssl/certs at all.\n\nSo the short answer is, yes, hard-coding /etc/ssl/certs as the path on \nOS X is incorrect and if setting /etc/ssl/certs as the path has the \neffect of replacing the default locations the verification will \nfail. Of course Apple patches the included version of OpenSSL \nstarting with OS X 10.6 to look in Apple's keychain, but if you're \nusing a MacPorts-built version that won't happen and still /etc/ssl/ \ncerts will be wrong in both cases.\n\nAs for the hint in that wiki/CACertificates link above, that does seem \nodd to me as well.\n\nA much better solution would be (if python simply MUST have a file) to \nexport the system's list of trusted root certificates like so:\n\n security export -k \\\n /System/Library/Keychains/SystemRootCertificates.keychain \\\n -t certs -f pemseq > rootcerts.pem\n\n # the generated rootcerts.pem file is suitable for use with the\n # openssl verify -CAfile option (root certs)\n\n # Substituting SystemCACertificates for SystemRootCertificates\n # produces a file suitable for use with the\n # openssl verify -untrusted option (intermediate certs)\n\nand then point python to that rootcerts.pem file. This file [2] may \nbe helpful in understanding what's in SystemRootCertificates.keychain \nand SystemCACertificates.keychain. The intermediate certs may also \nneed to be exported to a file and pointed to as well (a quick glance \nat the hgrc docs did not turn up an option for this).\n\n--Kyle\n\n[1] http://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/cryptlib.h#l84\n[2] \n"},{"id":"233295","messageId":"xmqqlhyexyp4.fsf@gitster.dls.corp.google.com","threadId":"35665","inReplyTo":"E036CD5E-69B1-4ABD-957B-8E31D410A897@gmail.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-17T18:14:47Z","receivedAt":"2014-01-17T18:14:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Kyle J. McKay\" writes:\n\n> On my OS X platform depending on which version of OpenSSL I'm using,\n> the OPENSSLDIR path would be one of these:\n>\n> /System/Library/OpenSSL\n> /opt/local/etc/openssl\n>\n> And neither of those uses a \"certs\" directory, they both use a\n> \"cert.pem\" bundle instead:\n>\n> $ ls -l /System/Library/OpenSSL\n> total 32\n> lrwxrwxrwx 1 root wheel 42 cert.pem -> ../../../usr/share/curl/\n> curl-ca-bundle.crt\n> drwxr-xr-x 2 root wheel 68 certs\n> drwxr-xr-x 8 root wheel 272 misc\n> -rw-r--r-- 1 root wheel 9381 openssl.cnf\n> drwxr-xr-x 2 root wheel 68 private\n> # the certs directory is empty\n>\n> $ ls -l /opt/local/etc/openssl\n> total 32\n> lrwxrwxrwx 1 root admin 35 cert.pem@ -> ../../share/curl/curl-\n> ca-bundle.crt\n> drwxr-xr-x 9 root admin 306 misc/\n> -rw-r--r-- 1 root admin 10835 openssl.cnf\n>\n> Notice neither of those refers to /etc/ssl/certs at all.\n>\n> So the short answer is, yes, hard-coding /etc/ssl/certs as the path on\n> OS X is incorrect and if setting /etc/ssl/certs as the path has the\n> effect of replacing the default locations the verification will fail.\n\nThe current code says \"if nothing is specified, let's pretend\n/etc/ssl/certs was specified. Then if it is a directory, use it\nwith SSL_ca_path, if it is a file, use it with SSL_ca_file, if it\ndoes not exist, do not even attempt verification.\"\n\nAnd that \"let's pretend\" breaks Fedora, where \"/etc/ssl/certs\" is a\ndirectory but is not meant to be used with SSL_ca_path---we try to\nuse /etc/ssl/certs with SSL_ca_path and verification fails miserably.\n\nIf I am reading the code correctly, if /etc/ssl/certs does not exist\non the filesystem at all, it wouldn't even attempt verification, so\nI take your \"the verification will fail\" to mean that you forgot to\nalso mention \"And on OS X, /etc/ssl/certs directory still exists,\neven though OpenSSL does not use it.\" If that is the case, then our\ncurrent code indeed is broken in exactly the same way for OS X as\nfor Fedora.\n\nThe proposed change in this thread would stop the defaulting\naltogether, and still ask verification to the library using its own\ndefault, so I can see how that would make the setting you described\nused on OS X work properly.\n\nIn short, I agree with you on both counts (the current code is wrong\nfor OS X, and the proposed change will fix it). I just want to make\nsure that my understanding of the current breakage is in line with\nthe reality ;-)\n\nThanks.\n"},{"id":"233326","messageId":"04260036-28A7-45CC-BD25-BED90A7C6DB4@gmail.com","threadId":"35665","inReplyTo":"xmqqlhyexyp4.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-01-17T23:34:08Z","receivedAt":"2014-01-17T23:34:08Z","isPatch":true,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jan 17, 2014, at 10:14, Junio C Hamano wrote:\n> If I am reading the code correctly, if /etc/ssl/certs does not exist\n> on the filesystem at all, it wouldn't even attempt verification, so\n> I take your \"the verification will fail\" to mean that you forgot to\n> also mention \"And on OS X, /etc/ssl/certs directory still exists,\n> even though OpenSSL does not use it.\" If that is the case, then our\n> current code indeed is broken in exactly the same way for OS X as\n> for Fedora.\n\nMy bad. That directory does not normally exist, but, if some errant \ninstaller were to create an empty one...\n\n> In short, I agree with you on both counts (the current code is wrong\n> for OS X, and the proposed change will fix it). I just want to make\n> sure that my understanding of the current breakage is in line with\n> the reality ;-)\n\nYes, you're right. :)\n"},{"id":"233773","messageId":"CALkWK0ky2KCJuo==XRiNu+eb2+hHpgv+FAyZTd85=TYQxgSCbQ@mail.gmail.com","threadId":"35665","inReplyTo":"xmqqppnry0p9.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2014-01-26T17:17:14Z","receivedAt":"2014-01-26T17:17:14Z","isPatch":true,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> This change could introduce a regression for people on a platform\n> whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL\n> somehow fails to use it as SSL_ca_path without being told.\n\nI can confirm that my git-send-email doesn't regress to the\npre-35035bbf state; my certificate directory is /etc/ssl/certs. I'm\nsomewhat surprised that IO::Socket::SSL picks the right file/\ndirectory on every platform without being told explicitly. This change\ndefinitely looks like the right fix.\n\nThanks.\n"},{"id":"233825","messageId":"xmqqlhy1pg4o.fsf@gitster.dls.corp.google.com","threadId":"35665","inReplyTo":"CALkWK0ky2KCJuo==XRiNu+eb2+hHpgv+FAyZTd85=TYQxgSCbQ@mail.gmail.com","subject":"Re: [PATCH] send-email: If the ca path is not specified, use the defaults","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-01-27T16:02:31Z","receivedAt":"2014-01-27T16:02:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra writes:\n\n> Junio C Hamano wrote:\n>> This change could introduce a regression for people on a platform\n>> whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL\n>> somehow fails to use it as SSL_ca_path without being told.\n>\n> I can confirm that my git-send-email doesn't regress to the\n> pre-35035bbf state; my certificate directory is /etc/ssl/certs. I'm\n> somewhat surprised that IO::Socket::SSL picks the right file/\n> directory on every platform without being told explicitly. This change\n> definitely looks like the right fix.\n\nThanks.\n"}]}