From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#71578: 29.3; ERC 5.5.0.29.1: No documented support for setting server and nickserv authentication per-server Date: Mon, 17 Jun 2024 11:00:51 -0700 Message-ID: <87frtb30vg.fsf__37534.3703360826$1718647350$gmane$org@neverwas.me> References: <8734pear4w.fsf@freakingpenguin.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27496"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 71578@debbugs.gnu.org, emacs-erc@gnu.org To: Richard Sent Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 17 20:02:23 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sJGgR-0006xs-GR for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Jun 2024 20:02:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sJGg9-0002tM-Oz; Mon, 17 Jun 2024 14:02:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sJGg5-0002s5-2E for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:02:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sJGg4-0004O3-QL for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:02:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sJGg6-0007bw-HV for bug-gnu-emacs@gnu.org; Mon, 17 Jun 2024 14:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Jun 2024 18:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71578 X-GNU-PR-Package: emacs Original-Received: via spool by 71578-submit@debbugs.gnu.org id=B71578.171864726729167 (code B ref 71578); Mon, 17 Jun 2024 18:02:02 +0000 Original-Received: (at 71578) by debbugs.gnu.org; 17 Jun 2024 18:01:07 +0000 Original-Received: from localhost ([127.0.0.1]:35306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJGfC-0007aM-Nn for submit@debbugs.gnu.org; Mon, 17 Jun 2024 14:01:07 -0400 Original-Received: from mail-108-mta218.mxroute.com ([136.175.108.218]:42847) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sJGf6-0007Zi-Vh for 71578@debbugs.gnu.org; Mon, 17 Jun 2024 14:01:05 -0400 Original-Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta218.mxroute.com (ZoneMTA) with ESMTPSA id 190275bee8a00017a3.001 for <71578@debbugs.gnu.org> (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 17 Jun 2024 18:00:54 +0000 X-Zone-Loop: f7f3e97ad104b000756970869a0ebf898d4b5fd40765 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2ZwPBMlj6UoQemRZrPTkATQdV1Ergr9w+9tNle4l7gw=; b=KIGabBzKEqZtvSWTFzKW3dhQ7p E+SpHfeVRGBUR3ZadQfLB18jHQMxkly4jPnklyskLYiqx5y6S0upttEH6LxvJ6VZ3HSr6ufUWggBq QsUcg2/T9NHP9A9vH/r0StkUDgMwHUTH9HbOF1miSzYEDOyBGLVpcn5WgbjvrCa+bXOYeNBfNPqKJ oPPOEvRh7dIjzvKkdO4P0qPmY0+QwrwMOeBujjTskCwfc/+Ue7+atCUa+MQUQamq9mv+igXSEICbx /fN+35lTAShne31eBk2CylXTdjqMz3RdEvIovgZTP6T0mPCKIvXaybtONvw8EWdieEsYTpC/BQCmm lPjILukQ==; In-Reply-To: <8734pear4w.fsf@freakingpenguin.com> (Richard Sent's message of "Sat, 15 Jun 2024 16:27:11 -0400") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287411 Archived-At: Hi Richard, Thanks for opening this. Richard Sent 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"))