[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#29108: 25.3; ERC SASL support
From: |
J.P. |
Subject: |
Re: bug#29108: 25.3; ERC SASL support |
Date: |
Mon, 23 Aug 2021 06:47:31 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Hi Ulrich,
"J.P." <jp@neverwas.me> writes:
> Then connect again (the client certs should be real, in preparation for
> the next demo):
>
> (push 'sasl erc-v3-extensions)
> (setq erc-v3-sasl-mechanism 'plain)
> (erc-tls :server "testnet.inspircd.org"
> :port 6697
> :nick "my-nick"
> :password "password123"
> ^~~~~~~~~~~~~~~~~~~~~~~ gone
> :full-name "My Nick"
I've changed things up a tad after realizing that appropriating the
dialed password parameter was a dumb idea. I guess in zealously adhering
to tradition (by mimicking erc-services.el, in this case), I also left
common sense at the door (yet again).
To clarify, I'm not talking about collisions with the legacy
PASS my-nick:password123
authentication scheme, for which there still remains dwindling support
among public networks. That's mostly a nonissue because SASL supplants
that entirely.
Instead, I'm thinking of actual server (connection) passwords, even
though they're basically unheard of with public networks. And I suppose
there's also the possibility of the rare proxy wanting a piece of the
PASS action for its own wacky purposes, something like a
PASS my-account@my-device/some-config-id:unused
preceding an SASL exchange moments later. (I haven't actually seen such
a thing in the wild, but it strikes me as plausible. Crazy?)
Anyway, since personal/enterprise IRC servers may still use actual
connection passwords, we've got to leave the `erc-tls' :password param
alone and introduce a separate SASL password option. Hope that's clear.
Also, in keeping with this policy, I've decided to discourage automatic
nick use for account user names. This also defies the ERC services API
but is nevertheless correct, IMO. So it's now
(setq erc-v3-sasl-user "my-nick"
erc-v3-sasl-password "password123")
or similar via M-x customize. BTW, auth source is consulted if you leave
the password out.
> This time, using EXTERNAL (note the lack of a password):
>
> (setq erc-v3-sasl-mechanism 'external)
In other news, EXTERNAL usage hasn't changed, though I'm wondering if we
should maybe add a warning when tried in conjunction with TLS1.2 (or
lower). Any idea if sub-1.3 is even possible on a modern Emacs and if
so, whether a warning after the fact would suffice? Something like a
(when (version< (substring (plist-get (gnutls-peer-status proc)
:protocol)
3)
"1.3")
(erc-display-error-notice nil "Warning: ..."))
except nicer perhaps? No idea. (@Lars or someone TLS savvy.)
Last side note: I'm thinking of moving the RPL_LOGGEDIN 900 handler out
of the erc-v3-sasl library or maybe instead defining a default that the
library can override when it loads. The reason is that some servers use
these numerics for confirming account authentication with the legacy
user:pass syntax noted above. And if we're trying to make sessions
account aware, this would accommodate people who for some reason still
want that user:pass stuff with v3 in lieu of SASL.
Anyway, when you have a sec, please try (again?) with these changes.
Thanks.
- Re: bug#29108: 25.3; ERC SASL support,
J.P. <=