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#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Mon, 07 Jun 2021 19:23:39 -0700 Message-ID: <878s3l6qms.fsf__42693.2057993085$1623119058$gmane$org@neverwas.me> References: <5495728.XOh7uYVVfo@ravel> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17724"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org To: Olivier Certner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 08 04:24:09 2021 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 1lqRPU-0004OW-TH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Jun 2021 04:24:09 +0200 Original-Received: from localhost ([::1]:46200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqRPT-0003Fz-Vd for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Jun 2021 22:24:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60114) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqRPO-0003Fo-JA for bug-gnu-emacs@gnu.org; Mon, 07 Jun 2021 22:24:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45597) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lqRPO-0000Vu-Cb for bug-gnu-emacs@gnu.org; Mon, 07 Jun 2021 22:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lqRPO-0002M1-4E for bug-gnu-emacs@gnu.org; Mon, 07 Jun 2021 22:24: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: Tue, 08 Jun 2021 02:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46777 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46777-submit@debbugs.gnu.org id=B46777.16231190319032 (code B ref 46777); Tue, 08 Jun 2021 02:24:02 +0000 Original-Received: (at 46777) by debbugs.gnu.org; 8 Jun 2021 02:23:51 +0000 Original-Received: from localhost ([127.0.0.1]:57143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqRPC-0002Lc-LE for submit@debbugs.gnu.org; Mon, 07 Jun 2021 22:23:50 -0400 Original-Received: from dal3relay254.mxroute.com ([64.40.27.254]:46783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqRPA-0002LP-W6 for 46777@debbugs.gnu.org; Mon, 07 Jun 2021 22:23:49 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by dal3relay254.mxroute.com (ZoneMTA) with ESMTPSA id 179e96ec8bf0000ce6.001 for <46777@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 08 Jun 2021 02:23:42 +0000 X-Zone-Loop: afc6cba46804e73c3e0def2407d1945d0fa9144167b5 X-Originating-IP: [149.28.56.236] In-Reply-To: <5495728.XOh7uYVVfo@ravel> (Olivier Certner's message of "Thu, 25 Feb 2021 18:33:53 +0100") X-AuthUser: 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" Xref: news.gmane.io gmane.emacs.bugs:208208 Archived-At: Hi Olivier, I'm sure you know this, but for others, both files have changed since this patch was created. It applies cleanly for me atop this commit: 297c0e0306f111c1e7564b2bb49a7e1a925a55bb Okay, the layout of this module is a bit confusing to me. Perhaps that's because it's regarded as an entry point of some kind and therefore special? In the commentary, it says to enable it explicitly using the minor mode interface (rather than add it to erc-modules). However, I notice that the :set function for the option erc-nickserv-identify-mode goes ahead and activates it in all the ways that matter (but the minor- mode variable). So no matter what, the function of the same name is called, which then sets the same custom option (possibly again). I guess that's what that comment about avoiding "recursive load at startup" is all about? For now, I'll just assume something fancy's going on I don't yet comprehend. (Maybe I'll check the old mailing list for clues.) In general, I'm somewhat inclined to regard this module as nonessential and legacy focused because it's not loaded by default and because these days, things seem to be trending toward fewer interactions with nick services beyond initial setup (where manual piloting is required anyway). However, I think this module receives a fair amount of attention on #emacs and elsewhere, so we might as well abide. Because I don't use it myself, I'll spare you any dubious hands on feedback and stick to the self-interested stuff affecting those improvements I'd like to see in ERC for this coming release. So, despite its specialness, I'm rather confident this module and your changes to it will be spared the brunt of the library-wide modifications I have in store. Basically, this would be a reorienting of ERC's notion of connection identities toward a more network-centric view. This module already depends on erc-networks, which is good. This means most of what I'll be tweaking will be auth-source related. But I won't touch any options concerning the when and the why of it all, which is what you and Leon have addressed. I'll instead likely only be messing with the arguments to the one auth-source-search invocation. If you're interested in details, please follow bug #48598. A couple specifics. In erc-nickserv-get-password, (erc-with-server-buffer (setq network erc-network ^~~~~~~~~~~~ server erc-session-server port erc-session-port)) would you mind using the function form of erc-network instead? I'm focusing a lot on that one symbol in particular, and it'd be nice to keep things consistent for now, if it's all the same to you. My other note concerns erc-nickserv-identify. Assuming debug-on-error is nil, it looks like this dings whenever erc-nickserv-get-password comes up empty, which I guess can only happen when the three main password-related user options are all nil (or the prompt gets dismissed). So, worst case scenario, people get dinged a few times straight away: maybe once just after MOTD and once just before, in the case of an initial re-NICK, and maybe again from a "please identify"/"nick taken" NOTICE. But being Emacs users, they'd know to check *Messages* for details (is that the idea?). If there's a realistic chance of a more intense onslaught, I suppose one alternative might be to print something to the active buffer using erc-display-error-notice instead. But you know better than I, having actually used this. Not sure if you're aware, but there's a bit of an integration going on between erc-join.el and this module via erc-nickserv-identified-hook. The autojoin module is pretty confusing, and my current bug addresses some of that. My question for you is: do networks punish folks for repeated failed JOIN attempts while unauthed? IOW, any clue whether major IRCds or service daemons auto-TKLINE (or similar) for such behavior? If there *is* a risk, I'd rather fix things on the autojoin side because inhibiting timers during read-passwd would affect PONGs and the outgoing flood queue, etc. BTW, have you considered maybe generalizing this entire module (while preserving the interface) to make it work with *any* services bot, e.g., FooServ, and not just nick-related stuff? So, yeah, now comes the part where I admit to not having actually fired this up and put it through its paces. But I'm certainly willing to if you'd like the extra peace of mind. Shouldn't take more than a couple days (i.e., nanoseconds to the yogi you've surely become by now). Let me know, and thanks. J.P.