patchgit-imap-send.txt: remove the use of sslverify=false in GMail example

Since GMail is SSL capable there is no need to set sslverify to false, the example using it may confuse readers that it's needed since it's also used in the previous example configurations, too

Signed-off-by: Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com>
---
 Documentation/git-imap-send.txt | 1 -
 1 file changed, 1 deletion(-)

Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com> writes:

Thanks.

While removing that item from the configuration is a good thing to do in the post 1.8.2.1 era, the reason why it is does not have much to do with "GMail is SSL capable".

The configuration item is not about "Do we connect over SSL when talking to this host?", but is about "When we use SSL with this host, do we verify the certificate it gave us?".

The reason why we can run with sslverify=true against gmail is because we know imap.gmail.com gives a validly signed certificate that leads all the way to a root CA the user's OpenSSL installation is likely to trust (if your hand-rolled imap-over-ssl server uses a snakeoil certificate, even though the server may be "SSL capable", you may not be able to successfully connect to it without sslverify turned off).

Side note. Before 1.8.2 and/or 1.8.1.4, git-imap-send did not implement sslverify correctly; CVS-2013-0308 was inherited from its origin "isync", where it _did_ verify the certificate is valid, but did not make sure the certificate was for the host it thought it was talking with.

Also note that 1.8.2.1 and/or 1.8.1.6 were the first versions that support Server Name Identification (RFC4366). Connection with older versions of git-imap-send over SSL to hosts like googlemail.com that multi-home different SSL hosts can receive a valid certificate for another host that sits at the same IP address, which will lead to the sslverify check to fail.

On 04/10/2013 09:44 PM, Junio C Hamano wrote:

My pleasure.

Should I change the commit message in order to avoid confusion among devs that read it?

If I change it, how should it sound? It could be:

Since GMail's certificates can be sslverify-ed there is no need to set sslverify to false, the example using it may confuse readers that it's needed since it's also used in the previous example configurations, too.

Have a nice day!

On Wed, Apr 10, 2013 at 11:44:03AM -0700, Junio C Hamano wrote:

Maybe imap-send should learn imap.sslCAInfo and imap.sslCAPath like http.* to handle custom certificates.

I think we should remove sslverify = false from the other example as well. "Recommending" sslverify = false is IMHO a bad idea as SSL provides no protection without verification.

Regards Simon

On 04/11/2013 06:26 PM, Simon Ruderich wrote:

Yep, that was why I thought there should be at least an example without it.

Should I create a new patch removing them all?

On Thu, Apr 11, 2013 at 06:55:03PM +0300, Barbu Paul - Gheorghe wrote:

Sounds like a good idea to me. And update the commit message with Junio's suggestions.

Regards Simon

Since SSL provides no protection if the certificates aren't verified it's better not to include sslverify=false in the examples. Also in the post 1.8.2.1 era git is able to properly verify the validity of a certificate as well it's origin.

Signed-off-by: Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com>
---
 Documentation/git-imap-send.txt | 2 --
 1 file changed, 2 deletions(-)

Barbu Paul - Gheorghe <barbu.paul.gheorghe@gmail.com> writes:

It is amusing that an MTA can mangle such a short patch this badly.

Count the number of preimage lines in the first hunk and you see only 5 lines but you claim it has 7. Where did the other two go? The second hunk has the same problem. "@@" that introduces the second hunk is not at the leftmost column. Where did the leading SP come from?

The examples in the documentation are primarily to demonstrate how the supported configurations and options can be used and for what purpose. its secondary purpose is to nudge the readers into the best practice.

So I'd suggest a patch that does these things instead of just removing these two:

 (0) Remove the duplication between the Examples header with ~~~~~~
     underline and the EXAMPLE header with ------ underline.

 (1) Use the second hunk of your patch to remove sslverify=false
     from that imap.gmail.com example.  As a public service, it is
     unlikely that the server side is configured to throw a
     certificate that does not verify at you.

 (2) Instead of removing sslverify=false in the imap.example.com
     example, comment it out like this:

     -	sslverify = false
     +	; sslverify = false

     Then mention that the user may want to use sslverify=false
     while troubleshooting, if he suspects that the reason he is
     having trouble connecting is because the certificate he uses at
     the private server at example.com he is trying to set up (or
     has set up) may not be verified correctly.