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

[Ted Zlatanov]

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