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

[Ivan Shmakov]

>>>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> On Sat, 26 Dec 2015 22:15:45 +0100 Lars Ingebrigtsen wrote:

 >> As Stefan said in a different report -- perhaps we should just
 >> require Emacs with built-in TLS support if you want to use TLS.
 >> That would essentially mean that we should just remove tls.el and
 >> starttls.el.
  
 >> Alternatively we could, in Emacs 25.1, just remove the --insecure
 >> settings

        FWIW, I tend to support this option.

 >> and let people who try to connect to their IMAP server just fail
 >> somewhat mysteriously (it's very common to have self-signed certs
 >> for IMAP).

        I see little value in self-signed certificates in general,
        especially given that there’s for a long-time a community-driven
        CA who offer X.509 certificates free of charge.

        Sure, for a small group, and assuming typical “desktop” TLS
        clients, self-signed certificates can be used to implement a
        public key dissemination model akin to that’s typical of SSH.
        However, I’ve seen them being used on MXes facing the world
        (say, the MX that serves bugs.debian.org), and I fail to see any
        point whatsoever in that.

 > I am in favor of either option and I think the first is cleaner.

 > There will be a small but vocal group that wants to use the external
 > tunnel utility.

        … Or there will be a group with a small number of its members
        being vocal; the difference may be not that easy to tell.

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

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

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

        I’ve sure seen external utility support in other software, too.
        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.

        As long as the hooks are in place to route the requests via that
        package, I have no (strong) objections to the move.  But given
        that tls.el is about 300 LoC in total, and hardly incurs a high
        maintenance cost, I don’t see much value in the move, either.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A