From: "J.P." <jp@neverwas.me>
To: 29108@debbugs.gnu.org
Cc: emacs-erc@gnu.org, bandali@gnu.org
Subject: bug#29108: 25.3; ERC SASL support
Date: Wed, 16 Nov 2022 06:51:27 -0800 [thread overview]
Message-ID: <875yfflzps.fsf__38085.6396209978$1668610360$gmane$org@neverwas.me> (raw)
In-Reply-To: <87y1sdk1fg.fsf@neverwas.me> (J. P.'s message of "Mon, 14 Nov 2022 07:20:35 -0800")
Some last-minute thoughts on the previous iteration.
In 0005-Add-non-IRCv3-SASL-module-to-ERC.patch:
> diff --git a/doc/misc/erc.texi b/doc/misc/erc.texi
> index 5049710b32..8eb33c8e80 100644
> --- a/doc/misc/erc.texi
> +++ b/doc/misc/erc.texi
> @@ -78,6 +78,7 @@ Top
> [...]
> +
> +Note that @code{sasl} is a ``local'' ERC module, which various library
> +functions, like @code{erc-update-modules}, may treat differently than
> +global modules in user code. However, this should not affect everyday
> +client use. To get started, just add @code{sasl} to
> +@code{erc-modules} like any other module. But before that, please
> +explore all custom options pertaining to your chosen mechanism.
An earlier version mentioned that users can customize per-network SASL
settings by let-binding `erc-sasl-*' options and `erc-modules' around
`erc-tls' invocations. I'm doubtful this is a sustainable approach and
would guess that a more declarative solution is the likeliest way
forward, perhaps something based on connection-local variables.
That said, I think users still need a practical solution to tide them
over in the short term, one that doesn't involve hooks or timers. And
since this module already takes a snapshot of its own options on
initialization (for reconnection purposes), we might as well revert to
mentioning let-binding, but this time also stress (maybe in an Advanced
chapter) that local modules are still being fleshed out and that
third-party implementations aren't yet encouraged.
> diff --git a/lisp/erc/erc-sasl.el b/lisp/erc/erc-sasl.el
> new file mode 100644
> index 0000000000..a9d7ed235d
> --- /dev/null
> +++ b/lisp/erc/erc-sasl.el
> @@ -0,0 +1,433 @@
> [...]
> +;;
> +;; TODO:
> +;;
> +;; - Find a way to obfuscate the password in memory (via something
> +;; like `auth-source--obfuscate'); it's currently visible in
> +;; backtraces and bug reports.
Just backtraces, not bug reports.
> [...]
> +
> +;; This stands alone because it's also used by bug#49860.
> +(defun erc-sasl--init ()
> + ;; When reconnecting, try to recover stashed parameters.
> + (let ((existing (assoc erc-networks--id erc-sasl--session-options
> + #'erc-networks--id-equal-p)))
> + ;; This likely only runs when `erc' was called with an :id keyword.
> + (when (and existing (not erc--server-reconnecting))
> + (setq erc-sasl--session-options (delq existing erc-sasl--session-options)
> + existing nil))
> + (setq erc-sasl--state (make-erc-sasl--state)
> + erc-sasl--options (or (cdr existing)
> + `((user . ,erc-sasl-user)
> + (password . ,erc-sasl-password)
> + (mechanism . ,erc-sasl-mechanism)
> + (authzid . ,erc-sasl-authzid))))))
> +
We should probably register a local `erc-kill-server-hook' that deletes
whatever's stored in `erc-sasl--session-options' for the current network
context.
> [...]
> +
> +(defun erc-sasl--on-connection-established (&rest _)
> + (setf (alist-get erc-networks--id erc-sasl--session-options nil nil
> + #'erc-networks--id-equal-p)
> + erc-sasl--options
> + ;;
> + erc-sasl--options nil))
> +
We could just drop `erc-sasl--options' completely and use a getter to
retrieve values from the global `erc-sasl--session-options' store.
That'd be one less point of failure as far as password exposure is
concerned. And, in the future, whatever context-aware abstractions
emerge for making granular options a thing should obsolete all this
ugly stashing business anyhow.
next prev parent reply other threads:[~2022-11-16 14:51 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.
[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.
[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-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
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. [this message]
[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='875yfflzps.fsf__38085.6396209978$1668610360$gmane$org@neverwas.me' \
--to=jp@neverwas.me \
--cc=29108@debbugs.gnu.org \
--cc=bandali@gnu.org \
--cc=emacs-erc@gnu.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).