Re: bug#29108: 25.3; ERC SASL support

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.