[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: |
Wed, 16 Nov 2022 06:51:27 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: bug#29108: 25.3; ERC SASL support, (continued)
- Re: bug#29108: 25.3; ERC SASL support, Adam Porter, 2022/11/10
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/10
- Re: bug#29108: 25.3; ERC SASL support, Adam Porter, 2022/11/10
- Re: bug#29108: 25.3; ERC SASL support, Akib Azmain Turja, 2022/11/11
- Re: bug#29108: 25.3; ERC SASL support, Adam Porter, 2022/11/14
- Re: bug#29108: 25.3; ERC SASL support, Akib Azmain Turja, 2022/11/11
- Re: bug#29108: 25.3; ERC SASL support, Adam Porter, 2022/11/14
Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/13
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/14
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/17
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/18
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/19
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/20
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/21
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/22
- Re: bug#29108: 25.3; ERC SASL support, Amin Bandali, 2022/11/23
- Re: bug#29108: 25.3; ERC SASL support, J.P., 2022/11/25