bug#71578: 29.3; ERC 5.5.0.29.1: No documented support for setting server and nickserv authentication per-server

["J.P." <jp@neverwas.me>]

Hi Richard,

Thanks for opening this.

Richard Sent <richard@freakingpenguin.com> writes:

> Hi all,
>
> When using ERC, various servers have different policies for nickserv
> identification and server authentication. For example, irc.libera.chat
> forwards the server password to nickserv, while irc.pine64.org ignores
> server password and nickserv is authenticated separately.
>
> By default, erc uses auth-source for server authetication
> (erc-auth-source-server-function), and can optionally use auth-source
> for nickserv identification (erc-use-auth-source-for-nickserv-password).
> These settings are global and affect every server.
>
> This causes problems where credentials may be needlessly
> double-decrypted using auth-source. This is particularly annoying when
> auth-sources needs to decrypt data and requires manual intervention
> (such as touching a yubikey).

I agree that it's far from ideal to have `services' perform lookups
whenever the options `erc-use-auth-source-for-nickserv-password' and
`erc-auth-source-services-function' are non-nil. And arranging for an
auth-source query to come up empty for connections you're not interested
in isn't a viable solution because `erc-nickserv-identify' won't take no
for an answer. Indeed, failing to provide a password when prompted
currently earns you an error, as you've no doubt observed.

I think the main issue here is that the global `services' module lacks
sufficient per-session granularity, which extends to its auth-source
integration. While auth-source is session aware by nature, ERC's
integration is not, at least not in the sense that different values for
the various `erc-auth-source-*-function' options can be specified per
session. (Of course, you *can* set these options to function values that
are themselves session aware, but that defeats the purpose of deferring
to the framework to begin with.)

All this echoes a familiar gripe among users regarding ERC's inability
to apply existing options, like `erc-auth-source-join-function', in a
targeted fashion that's limited to a specific context, such as a certain
channel on a given network [1]. In fact, a long-term goal of this
project is to address this in a more general way, possibly by proposing
a change to Emacs' Custom machinery itself that would make user options
relatable to arbitrary "contexts" in a manner somewhat reminiscent of
connection-local variables, only more abstract.

> This occurs because the auth-source specification for server
> authentication and nickserv authentication do not necessarily match so
> the cached result is not returned. (For example, libera.chat has
> iridium.libera.chat, mercury.libera.chat, etc. which are passed in the
> spec for nickserv authentication, while irc.libera.chat is passed for
> server authentication.)

I think disparities in query behavior across contexts is an overlapping
concern best tackled independently. By default, ERC favors the network
ID when matching against the `:host' parameter for all authentication
opportunities except server passwords. This means you can specify an
entry like

     machine Libera.Chat login MyNick password sEcReT

instead of

     machine foo.libera.chat ...
     machine bar.libera.chat ...
     machine baz.libera.chat ...

where "Libera.Chat" is the network ID. However, as you've likely
discovered, this won't work for server passwords because ERC doesn't yet
know the network ID when it sends the "PASS" command. As things
currently stand, if you want to avoid a redundant

     machine irc.libera.chat ...

you can invoke your entry point command from lisp with a session ID,
like

  (erc-tls ... :id "Libera.Chat" ... )

which then takes precedence over any discovered network ID. (BTW, though
this won't help with your issue, the manual for the latest release
contains expanded coverage of ERC's auth-source integration [2].)

Anyway, at present, folks bothered by this behavior will have to write
their own lookup function, which is perhaps a bridge too far for
relatively simple cases like the one you describe. I think the situation
can be improved a bit by doing the following:

  1. Add an option to reverse the ordering favored by
     `erc-auth-source-search', which is the default value of all
     `erc-auth-source-*-function' options. Basically, we'd want

       machine irc.libera.chat ...

     to always win over

       machine Libera.Chat ...

     so people can optionally only specify the (dialed) one.

  2. Cache the value of `erc-auth-source-server-function' given at
     initial connection time for reuse when reconnecting, much like we
     do with `erc-session-password' and `erc-session-connector'. (The
     `sasl' module already does this for `erc-sasl-auth-source-function'
     because it's a so-called "local" module.) This should obviate the
     need for your :password "" workaround for those willing to let-bind
     `erc-auth-source-server-function' to nil around calls to `erc-tls'.

> Ideally ERC should have a documented method for disabling server
> authentication and nickserv authentication on a per-server basis. As a
> workaround I found the following methods currently work:
>
> ;; Note that these must be "", not nil
>
> ;; Pass :password "" to disable server authentication
> (erc-tls :server "irc.pine64.org"  :nick "freakingpenguin" :password "")

AFAICT, this makes ERC send an opening "PASS :" message. Although IRC
syntax does allow for an empty trailing parameter, I couldn't find
anything documenting how servers should treat an empty server password
specifically. As such, if documenting :password "" as a workaround to
suppress lookups of server passwords, we'd probably want to indicate
that it's only known to work on certain servers.

> ;; Set nickserv password to "" to disable nickserv authentication
> (setq erc-nickserv-passwords '((Libera.Chat (("freakingpenguin" . "")))))

For some reason, this one gives me the familiar "Cannot find a password
for nickname ..." error. Stepping through `erc-nickserv-get-password' on
ERC 5.5, I see that it correctly determines the password to be "", but
the line

  (not (string-empty-p (erc--unfun ret)))

makes it return nil, which then triggers `erc-nickserv-identify' to
signal the aforementioned error.

> As far as I'm aware this isn't documented anywhere officially so there's
> no guarantee it will continue to work in the future.

Sadly, individual modules aren't yet documented in ERC's manual. I'd
very much like to change that at some point (patches welcome).

Anyway, I've distilled some thoughts on this issue cobbled together from
various notes and earlier discussions:

- Problem: ERC doesn't support connecting simultaneously to a server
  allowing only NickServ-based authentication and another requiring a
  different method, such as a server password. In essence, the
  `services' module cannot be enabled for only a subset of connections.

- Workaround: shadow unwanted entries

  This only works when `erc-nickserv-identify-mode' is set to `both'
  (the default). For each network you *don't* want managed, add an
  entry, like:

    (setopt erc-nickserv-alist
            (cons (list 'foonet nil regexp-unmatchable "" "" nil nil nil)
                  erc-nickserv-alist))

  Or do the equivalent via Customize. Then connect as usual, and
  services will only attempt to authenticate to servers with
  non-shadowed entries.

- Workaround: use the library but not the module

  That is, don't add `services' to `erc-modules' at all. Instead, load
  the library, and selectively mimic the module by adding only the hook
  members you need. For example, to force your way past a server that
  sends a "433 ... Nickname is reserved" response to an opening "NICK
  mynick" message (which induces ERC to ask for and be granted "mynick`"
  instead), ensure the relevant entry in `erc-nickserv-alist' has t for
  its 6th field so that ERC sends "NickServ IDENTIFY mynick mypass"
  instead of just "NickServ IDENTIFY mypass".

    (require 'erc-services)
    
    (setopt erc-nickserv-alist
            (cons '(foonet "irc.foonet.org" nil
                           "NickServ" "IDENTIFY" t ; <- important
                           nil "You're now logged in as ")
                  erc-nickserv-alist))
    
    (defun my-erc-identify-on-connect (server _my-backticked-nick)
      (when (string-suffix-p ".foonet.org" server)
        ;; Replace "mypass" with nil to defer to `erc-nickserv-get-password'
        (erc-nickserv-identify "mypass" "mynick")))
    
    (add-hook 'erc-after-connect #'my-erc-identify-on-connect)
    (erc :server "127.0.0.1" :port 6667 :nick "mynick")

- Solution: new "ignore" option

  A hypothetical `erc-nickserv-ignore-without-alist-entry' option, could
  address this issue by telling ERC to forgo authenticating to networks
  that don't have an entry in `erc-nickserv-alist'.

- Solution: new `services-local' module

  Such a module would address this issue by only managing NickServ
  dialogues for connections that enable it during entry-point
  invocation. It could share options with the global `services' module
  or offer its own, simplified ones. Either way, it would act like other
  local modules in stashing a copy of its options when initializing and
  then reusing them when reconnecting. Users could then be free to
  let-bind different configurations around calls to `erc-tls'.

> This is intended as a tracking ticket following discussion on #erc.

Better (two decades) late than never!

Cheers,
J.P.

P.S. You may be able to use the `sasl' module for Pine64.org because
they appear to be running a relatively recent version of Unreal [3].


[1] https://lists.gnu.org/archive/html/erc-discuss/2012-05/msg00008.html

[2] https://elpa.gnu.org/packages/doc/erc.html#auth_002dsource

[3] After registering, I was able to authenticate successfully to
    Unreal's testnet with the following session-local configuration:

    (let ((erc-modules (cons 'sasl erc-modules)))
      (erc-tls :server "irc.unrealircd.org"
               :nick "mynick"
               :user "mynick"
               :password "mypass"))