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: Wed, 09 Jun 2021 20:59:54 -0700 Message-ID: <87tum6nzd1.fsf__28567.7997789875$1623297680$gmane$org@neverwas.me> References: <5495728.XOh7uYVVfo@ravel> <878s3l6qms.fsf@neverwas.me> <1960033.R0FQcr2YjX@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="35687"; 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 Thu Jun 10 06:01:16 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 1lrBsY-0009AB-86 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 06:01:14 +0200 Original-Received: from localhost ([::1]:53996 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrBsX-00082D-69 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 10 Jun 2021 00:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrBsN-000822-1h for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 00:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51763) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lrBsM-0003gT-3z for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 00:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lrBsM-0006Lx-3J for bug-gnu-emacs@gnu.org; Thu, 10 Jun 2021 00:01: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: Thu, 10 Jun 2021 04:01: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.162329761124359 (code B ref 46777); Thu, 10 Jun 2021 04:01:02 +0000 Original-Received: (at 46777) by debbugs.gnu.org; 10 Jun 2021 04:00:11 +0000 Original-Received: from localhost ([127.0.0.1]:35076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrBrW-0006Km-Q5 for submit@debbugs.gnu.org; Thu, 10 Jun 2021 00:00:11 -0400 Original-Received: from mail-110-mta119.mxroute.com ([136.175.110.119]:37825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrBrS-0006I1-T5 for 46777@debbugs.gnu.org; Thu, 10 Jun 2021 00:00:08 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-110-mta119.mxroute.com (ZoneMTA) with ESMTPSA id 179f413a439000a2c9.001 for <46777@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 10 Jun 2021 03:59:58 +0000 X-Zone-Loop: 4808ed474e1451fe8bfe21cc41528721df26088e7b44 X-Originating-IP: [149.28.56.236] In-Reply-To: <1960033.R0FQcr2YjX@ravel> (Olivier Certner's message of "Wed, 09 Jun 2021 15:30:55 +0200") 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:208310 Archived-At: > I have very limited time at the moment, so I'm sure I'm not going to be able > to look at it before next week, and perhaps even before next month. Are you > (or is someone) aware of the expected release cycle for 28.1? Thanks for the time window. It would be nice to get the patches you have open into ERC before the next release, but I'm clueless as to when that's slated to occur. > Didn't dig that, but can tell you "services" indeed works when added to `erc- > modules', since this is how I'm using it. If I don't put it there, no autojoin > happens when NickServ responds. I wasn't worried about it not supporting the modules interface. I was concerned that setting `erc-nickserv-identify-mode' in a config via `set-variable' or similar would effectively turn it "on" by registering its hooks even though `erc-services-mode' (the variable) would still be nil (because this module isn't loaded by default). Regardless, shouldn't we try to keep those in sync? If not, and module-based minor modes shouldn't be used to detect whether a module is active and its features enabled, then we've got to fix that in the code (right?), perhaps starting with (unless erc-networks-mode ;; Force-enable networks module, because we need it to set ;; erc-network for us. (erc-networks-enable)) in (the function) `erc-nickserv-identify-mode' itself. > I've seen you sent a big mail entitled "buffer-naming collisions involving > bouncers in ERC" but only had time for a quick glance. > > As for interaction with NickServ, every new direct connection to servers need > to authenticate with NickServ when using a registered nick. I don't know how > bouncers work, but I suspect they do authentication differently, so I suspect > your view is that of a user of bouncers. I should apologize for not de-emphasizing "bouncer" in reference to my concerns being influenced by that bug (#48598), which for me is merely a convenient means of addressing larger fundamental problems in ERC. > Architecturally, I don't know (yet) if having this module separate is a good > thing going ahead, but on the other hand I think the need for auto-joining is > very real (again, may be wrong with bouncers; do they automatically forward > all messages from all channels they are in to clients connecting to them? or > is there a specific mechanism to obtain the messages from specific channels?). > And autojoining cannot work effectively if users are not automatically > identified before (when using registered nicks). So the module/architecture > may be obsolete, but I don't think the needs themselves are. The real problem (to my knowledge) is that there's no consensus around how an IRC server should tell a client it's been authenticated (work may be ongoing in this area). For now though, since there's no formal concept of "accounts," you're either granted the nick you requested during opening introductions or you're not. How one goes about creating the conditions for such "granting" to occur successfully depends on the various methods available to the client and the server. Extensions like SASL support (part of the v3 initiative) and Cert FP, which uses client certificates, are two examples of methods currently employed by networks and servers to address this. Personally, I wouldn't like to see this module loaded by default unless we can state confidently that the way in which it goes about solving this problem, namely engaging nick services with heuristics-driven, TCL-expect style exchanges (which is fine) is the right thing for most users (it very well may be). More on this general topic of what determines a session in my bug's thread (#48598). > Given my limited time at the moment, yes, it would be best that your changes > are quite small if you want me to review them. For this module, that's looking likely. > I'll follow up with #48598 when I can. > > So here's a first proposal: > 1. I rebase the changes on current master. > 2. We address what needs to be addressed with respect to your other patches. Step 2 isn't really necessary unless you feel up to it. I'm fine with just dropping it rather than having us waste time coordinating around something that's still mostly fluid. >> A couple specifics. In erc-nickserv-get-password, >> [...] >> would you mind using the function form of erc-network instead? Don't bother with this. I shouldn't have brought it up. > In ERC in general, I've found that there are too many buffer-local variables > and accessor functions in the sense that they are redundant, that you don't > necessarily know in which buffer to look for which variable (current buffer? > server buffer? other?), and that multiple variables seem to contain > approximately the same information (but not exactly, that would be too > simple). Proper accessors could solve part of these problems (doing that with > a minimal amount of buffer switching is more work, but can wait for later). We definitely agree on this point. At the moment though, I'm trying to resist refactoring in this area in full. Instead, I'd like to turn this corner in stages, the first adding whatever's necessary to tackle #48598 (which again, has to do with much more than just bouncers). > I get prompted once only (in fact, now not at all, since I use auth-source). I > never re-NICK. What are re-NICKs used for? To wear cloaks after regular log > in? In this case, I assume NickServ authentication is needed for logging in, > but not to switch to the cloak? Sorry, I'm not yet very versed in the > subtleties of IRC, contrary to what you may think. By re-NICK, I meant the server sending you a :you`!~you@yours NICK :you once you've been authenticated. Do you not get these? In terms of dinging, I wasn't really referring to your personal experience but rather a worst case for an unlucky user. As long as the error message and how it's displayed is sufficient for getting someone on their way toward fixing the issue, then fine by me. > 1. I can't answer your question about being banned if attempting too much to > join while not authenticated. But why is this even a problem? In which case > are we going to repeatedly join some channel after a failed attempt? Don't worry about the ban thing. This was based on my carelessly missing the fact that `erc-nickserv-identified-hook' only runs after you're successfully authenticated. For whatever reason, I thought it ran on 376 when `erc-nickserv-identify-on-connect' fires, but that's not the case. Currently, the first autojoin timer is only set on 376 and fires after 30 seconds. In the most unlikely scenario, an unlucky user with no auth source and no options configured and who can't get their act together before the timer runs will only log a single failed attempt. Clearly not something to worry about. I doubt any public network would consider that an infraction. Also fueling my original concern was this phenomenon we've been seeing of various networks enacting stricter policies for some IP ranges and individuals. That this would somehow involve attempts to use the network before being auth'd was unfounded speculation on my part. > 2. `read-passwd' doesn't inhibit timers (AFAIK). Why would you want to inhibit > timers there? Having a time out in `erc-nickserv-identify' would be great yes. > Is this what you are talking about? Sorry, that wasn't clear. I didn't mean to imply `read-passwd' inhibited timers while running. I meant we shouldn't do that as a sad workaround for postponing JOIN timers.