[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19284: 25.0.50; tls.el uses option --insecure
From: |
Ivan Shmakov |
Subject: |
bug#19284: 25.0.50; tls.el uses option --insecure |
Date: |
Tue, 29 Dec 2015 19:25:48 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
>>>>> 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