bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications

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

Olivier Certner <olce.emacs@certner.fr> writes:

> * lisp/erc/erc-services.el (erc-nickserv-identify): Don't take the
> password anymore as an argument (and don't prompt for it
> interactively).  On the contrary, now take the nick to use for
> identification (interactively, ask for it, defaulting to the current
> one).  Move actual message sending into the new
> `erc-nickserv-send-identify', and password prompting into
> `erc-nickserv-get-password'.
>
> [...]
>
> -;;;###autoload
> -(defun erc-nickserv-identify (password)
> [...]
> +;;;###autoload
> +(defun erc-nickserv-identify (&optional nick)
> +  "Identify to NickServ immediately.

Hi Olivier, this concerns your changes to the autoloaded command
`erc-nickserv-identify'. Someone seeking help for a loosely related
issue shared this on Libera today:

  (defun uh-erc-identify ()
    (let ((pass
           (let ((s (shell-command-to-string "pass malc@irc.libera.chat")))
             (substring s 0 -1))))
      (erc-nickserv-identify pass)))

It strikes me that other folks may be doing the same, namely, using this
function in lisp code. So just to settle some imaginary nerves, it might
help to flesh out exactly why there's little risk of something
unfortunate/scary happening as a result of this interface change.

As I see it, the worst case scenario is that your password is sent in
place of your nick and ends up in the network's logs (where passwords
are normally redacted). If that's a realistic concern, perhaps you
should consider keeping the password param in its original position
for the sake of compatibility. Just a thought.

Also, I think the addition of the nick param bears some justifying too
because it may not be clear from your commit log and emails (or #45340)
why this is necessary. For me, the param is needed because some IRCds
and services daemons won't let you auth by passing your currently
assigned (perhaps unregistered) nick. In other words:

  PRIVMSG NickServ :IDENTIFY bob` mypass

or

  PRIVMSG NickServ :IDENTIFY mypass

won't work if you're trying to identify as "bob" and are currently
"bob`". But without the nick param you've added, a user would be forced
to issue the IRC command manually. Hope that's clear.

BTW, I've noticed that many services automatically re-NICK you as
confirmation of success, triggering `erc-nick-changed-functions', which
`erc-nickserv-identify-on-nick-change' is a member of by default. So you
get prompted again for no reason. (As you may be aware, double prompting
has also come up recently in the ERC channel, but I suspect the two are
unrelated.)

Anyway, I doubt you'll recall, but I tried (rather unconvincingly) to
raise this point earlier in this bug thread. If addressing this isn't in
the cards, then hopefully we can get a ruling on this patch and start
putting the days of scraping NickServ replies behind us (and begin
embracing the evolving standard). Thanks.