unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "J.P." <jp@neverwas.me>
To: Ulrich Mueller <ulm@gentoo.org>
Cc: 29108@debbugs.gnu.org, emacs-erc@gnu.org
Subject: bug#29108: 25.3; ERC SASL support
Date: Mon, 23 Aug 2021 06:47:31 -0700	[thread overview]
Message-ID: <87o89oi87g.fsf__42779.680183024$1629726514$gmane$org@neverwas.me> (raw)
In-Reply-To: <87mtprkkgi.fsf@neverwas.me> (J. P.'s message of "Mon, 09 Aug 2021 02:59:09 -0700")

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.





  parent reply	other threads:[~2021-08-23 13:47 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 20:07 bug#29108: 25.3; ERC SASL support Alex Branham
2017-11-10  2:24 ` Noam Postavsky
2019-10-23  9:24   ` Lars Ingebrigtsen
2019-10-23 10:34     ` Alex Branham
2019-10-23 11:19       ` Lars Ingebrigtsen
2019-10-23 12:19         ` Stefan Kangas
2019-10-23 12:57           ` Noam Postavsky
2019-10-23 13:32             ` Stefan Kangas
2019-11-02 14:10         ` Stefan Kangas
2020-08-03  9:39           ` Lars Ingebrigtsen
2021-07-28 16:59 ` Ulrich Mueller
2021-07-28 17:21   ` Eli Zaretskii
2021-07-28 22:42   ` J.P.
2021-08-09  9:59   ` J.P.
2021-08-09 10:22     ` Ulrich Mueller
2021-08-09 10:56       ` J.P.
2021-08-09 12:39       ` J.P.
2021-08-23 13:47     ` J.P. [this message]
     [not found]     ` <87o89oi87g.fsf@neverwas.me>
2021-08-23 14:01       ` Lars Ingebrigtsen
     [not found]       ` <87zgt8s1jt.fsf@gnus.org>
2021-08-24 13:42         ` J.P.
2022-09-18 18:32 ` bug#29108: [J.P.] Add "non-IRCv3" SASL to ERC J.P.
2022-09-20  6:07   ` bug#29108: 25.3; ERC SASL support J.P.
     [not found]   ` <875yhifujk.fsf_-_@neverwas.me>
2022-09-21 13:13     ` J.P.
2022-10-14  3:05       ` J.P.
     [not found]       ` <878rljxfxs.fsf@neverwas.me>
2022-10-26 13:14         ` J.P.
     [not found]         ` <87k04m4th8.fsf@neverwas.me>
2022-11-08 14:10           ` J.P.
     [not found]           ` <87o7thlepf.fsf@neverwas.me>
2022-11-09  4:08             ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-09 13:49               ` J.P.
     [not found]               ` <874jv81bn2.fsf@neverwas.me>
2022-11-09 17:50                 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                 ` <87iljoqaor.fsf@disroot.org>
2022-11-10  5:28                   ` J.P.
     [not found]                   ` <87sfirml89.fsf@neverwas.me>
2022-11-10 18:04                     ` Adam Porter
2022-11-10 21:50                       ` J.P.
2022-11-11  5:51                       ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-14 22:28                         ` Adam Porter
     [not found]                       ` <87sfiq7a3j.fsf@neverwas.me>
2022-11-11  1:25                         ` Adam Porter
2022-11-11  5:56                         ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]                         ` <878rkighkn.fsf@disroot.org>
2022-11-14 22:29                           ` Adam Porter
2022-11-13 15:36             ` J.P.
     [not found]             ` <87o7taoohd.fsf@neverwas.me>
2022-11-14  6:45               ` J.P.
2022-11-14 15:20                 ` J.P.
     [not found]                 ` <87y1sdk1fg.fsf@neverwas.me>
2022-11-16 14:51                   ` J.P.
     [not found]                   ` <875yfflzps.fsf@neverwas.me>
2022-11-17  6:30                     ` J.P.
     [not found]                     ` <877czuks8k.fsf@neverwas.me>
2022-11-17 15:28                       ` J.P.
2022-11-18  2:26                     ` J.P.
     [not found]                     ` <878rk9576b.fsf@neverwas.me>
2022-11-18 14:06                       ` J.P.
     [not found]                       ` <87leo8z79j.fsf@neverwas.me>
2022-11-19 14:48                         ` J.P.
     [not found]                         ` <87tu2vroeh.fsf@neverwas.me>
2022-11-20 14:29                           ` J.P.
     [not found]                           ` <87wn7pog1l.fsf@neverwas.me>
2022-11-21 15:09                             ` J.P.
     [not found]                             ` <87y1s4mjj6.fsf@neverwas.me>
2022-11-22 14:01                               ` J.P.
     [not found]                               ` <87r0xvks03.fsf@neverwas.me>
2022-11-24  2:49                                 ` Amin Bandali
     [not found]                                 ` <87r0xtnk24.fsf@gnu.org>
2022-11-25 14:43                                   ` J.P.
     [not found]                                   ` <87wn7jgkne.fsf@neverwas.me>
2022-11-28  0:08                                     ` J.P.
2022-11-29  5:19                                     ` Amin Bandali
     [not found]                                     ` <87iliyz6at.fsf@gnu.org>
2022-11-29 15:05                                       ` J.P.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='87o89oi87g.fsf__42779.680183024$1629726514$gmane$org@neverwas.me' \
    --to=jp@neverwas.me \
    --cc=29108@debbugs.gnu.org \
    --cc=emacs-erc@gnu.org \
    --cc=ulm@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).