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

[Ivan Shmakov <ivan@siamics.net>]

>>>>> 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