bug#19284: 25.0.50; tls.el uses option --insecure

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 29 Dec 2015 19:25:48 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

IS> 	To note is that Gnus’ nnimap method has its own “tunnel utility”
IS> 	support, which I use to interface the local IMAP server (below),
IS> 	and which (I suppose) could be used in place of tls.el.

IS>    (nnimap-stream shell)
IS>    (nnimap-shell-program "MAIL=maildir:\"$HOME\"/Maildir imapd")

IS> 	That said, the lack of possibility to use something similar for
IS> 	non-nnimap connections is not something I’d appreciate.

IS> 	I’ve sure seen external utility support in other software, too.
IS> 	Check the OpenSSH client’s ProxyCommand option, for instance.

>> I think the benefit to the rest of the users will be worth it, and
>> that group can have a ELPA package to support them.

IS> 	As long as the hooks are in place to route the requests via that
IS> 	package, I have no (strong) objections to the move.

The package itself will install those hooks, I assume.

IS> 	But given that tls.el is about 300 LoC in total, and hardly
IS> 	incurs a high maintenance cost, I don’t see much value in the
IS> 	move, either.

There's a small but consistent amount of time spent checking "are you
using tls.el?" every time we debug a SSL/TLS issue (even if we don't ask
the user explicitly).

There is a user experience difference between relying on external tools
implicitly, which tls.el does, and explicitly, which ProxyCommand does.
Also, tls.el is not granular like ProxyCommand or the `nnimap-stream'
functionality, it applies to all connectivity. I hope that explains my
reasoning better.

Ted