Re: Bug with imap.gmail.com and getmail TLS validation

On Mon 2019-02-11 20:20:11 -0600, Charles Cazabon wrote:
> Would you mind not distributing this yet?  I *really* dislike the support
> burden that results from having different options and patches in upstream vs
> various distributors' versions.

I'm not distributing it in debian yet (that's why i posted it here for
review), and i agree with you that the support burden of divergence
between upstream and downstream distros is a pain that i'd like to
avoid.

> The entire reason I posted that test script was to gather information so I
> could try to determine if it was safe to just unconditionally use SNI when
> support for it is present; I have no intention (as I mentioned elsewhere in
> this thread) of adding a `use_sni` option which 99% of users will not
> understand.  There's already way too much cargo-cult software configuration in
> the world.

agreed, i only added the option because it looked to me like you weren't
up for considering unconditional enabling of SNI, and i wanted a way
that users of that patch could fall back to standard upstream behavior
without having to rebuild.

I'd much prefer the scenario of always sending SNI as long as the python
module HAS_SNI.  Feel free to take just the part of the patch that does
that, and drop all the stuff around the use_sni= configuration.

> If you're looking for a short-term workaround, tell people to set the SSL
> version to TLS 1.2 or below, as also posted elsewhere in this thread.

Elsewhere in this thread i've explained why i think that is a move that
will lead to future breakage, and will keep people from getting the
benefits of stronger crypto.  This is true for *any* config settings
that fiddle statically with crypto protocols, even those that are trying
to force more modern crypt -- during the rollout of TLS 1.2, we saw
exactly this kind of breakage from people who had forced TLS 1.0 into a
config file somewhere because they meant "prefer this newfangled TLS
thing" (during the SSLv3 → TLS1.0 transition), but which ultimately
ended up keeping them from adopting the significantly better TLS 1.2.

I want to avoid asking people to add configuration workarounds that end
up being (accidentally) permanent.

Regards,

   --dkg

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXGMj4wAKCRB2GBllKa5f
+CRwAP9RfWTDxUsTAK0PHwlKlQCvMzFnf00y++sQjjnIUcrgrAEAhBh5uq3TO1rF
qxEa+9K8frSl9Pie/ZlVWwxZqHOv4QU=
=jLDs
-----END PGP SIGNATURE-----