[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: STARTTLS for erc
From: |
Ted Zlatanov |
Subject: |
Re: STARTTLS for erc |
Date: |
Thu, 23 Jun 2011 07:24:16 -0500 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) |
On Thu, 23 Jun 2011 02:54:52 +0200 Lars Magne Ingebrigtsen <address@hidden>
wrote:
LMI> So you have to know in advance that the server supports STARTTLS or not,
LMI> which is kinda, er, stupid.
LMI> However. After logging in, the servers seem to output a capability list
LMI> of sort during the login greeting. But at that point it's too late to
LMI> get STARTTLS support going. *sigh*
LMI> So erc could close the connection, and then restart it, now with
LMI> STARTTLS. But ircd logins are notoriously slow, so that's totally
LMI> icky.
I'd make "no" the default because that STARTTLS support is rare.
LMI> So perhaps something like the following would work? If erc sees that
LMI> the server supports STARTTLS, then it will store this data for future
LMI> reference. The next login will look up this data, and if the server
LMI> supports STARTTLS, it'll do STARTTLS.
LMI> But where would this per-server data be stored?
It could be in auth-source, together with the user name and password
which I am supposed to add eventually (I posted a patch on the
emacs-bugs list a month or two ago and haven't had the time to apply it
and test it). If you want, go ahead and use that patch. I would make
the STARTTLS preference a "tls" key with a "yes/no/opportunistic" value,
with "no" or missing meaning no STARTTLS should be done.
Otherwise you could store the STARTTLS preference in the server
definition of ERC itself.
LMI> And this would be somewhat brittle. If a server goes from one type
LMI> (supporting STARTTLS) to another (not supporting STARTTLS), it might
LMI> mean that the next login might fail.
I think that's really rare, unless you're hitting a DNS round-robin.
Ted