From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Olivier Certner Newsgroups: gmane.emacs.bugs,gmane.emacs.erc.general Subject: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Wed, 09 Jun 2021 15:30:55 +0200 Message-ID: <1960033.R0FQcr2YjX@ravel> References: <5495728.XOh7uYVVfo@ravel> <878s3l6qms.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7Bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28147"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 09 15:32:18 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 1lqyJe-00078v-5e for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 15:32:18 +0200 Original-Received: from localhost ([::1]:55924 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqyJd-0006PK-7Q for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 09:32:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqyJO-0006NV-Te for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2021 09:32:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lqyJO-0006b4-3F for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2021 09:32:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lqyJO-0004jE-0K for bug-gnu-emacs@gnu.org; Wed, 09 Jun 2021 09:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Olivier Certner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Jun 2021 13:32:01 +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.162324546715417 (code B ref 46777); Wed, 09 Jun 2021 13:32:01 +0000 Original-Received: (at 46777) by debbugs.gnu.org; 9 Jun 2021 13:31:07 +0000 Original-Received: from localhost ([127.0.0.1]:60819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqyIU-000401-Lu for submit@debbugs.gnu.org; Wed, 09 Jun 2021 09:31:07 -0400 Original-Received: from smtp5-g21.free.fr ([212.27.42.5]:54106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqyIQ-0003un-D9 for 46777@debbugs.gnu.org; Wed, 09 Jun 2021 09:31:05 -0400 Original-Received: from ravel.localnet (unknown [2.15.208.149]) (Authenticated sender: ocert.dev@free.fr) by smtp5-g21.free.fr (Postfix) with ESMTPSA id D53725FF27; Wed, 9 Jun 2021 15:30:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1623245461; bh=3PBtrXUnNeiMir60RyyRFxYjndcn45yRICbEjLr72kg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gEVsVsTbFtze3HCjno7Ur0jAAkhq48MG3J26wZD0l8mS5rVzLCO/pJAuj3tLt4O97 +E8jdF/rqRa1zDvTSzTf01oiGTJT2QwwrhqceZ+u6a7VuI7LVChzWkpxp3EsUPvFK2 z37+xikllnPHUN4Ylov6DFdisMNW0yvD644VeUBU6RhpFnjokxbjFvrMGUBHiizT0t JfowBpxUJU3Z0KNO2y7S6r5Tt95aRbAF9Xa94DQToFbYJOlJucRtheGGvZiaut4L8I hKTj26nlGAQoXCizTyM/ABowOYbt3YfSv8qHXlkJb2bsMILltmcJ/hs4jqWNx14QRk I3f/fM1bHtR7w== In-Reply-To: <878s3l6qms.fsf@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:208293 gmane.emacs.erc.general:1545 Archived-At: Hi, > 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 I didn't check for a long time because of the legal part taking so long (more than 7 months, I opted for public domain first but switched to regular copyright assignment thanks to the grant back) and because I'm maintaining private patches over Emacs 27.1. 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? > 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). 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. > 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. 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. 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. > 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. 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. 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. Provided, indeed, that I have time to do it quickly enough for 28.1's release. If not we'll have to find another plan. > 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. In principle I don't mind. But I also prefer simplicity as much as possible. If I chose this, it's probably because using the function had no added value. If the buffer-local variable and the function are indeed going to differ (hopefully you have good reasons for this) in your plans, of course we can switch. 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). > 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. 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. I don't think a priori that there is a problem in dinging the user per se, even a few times. The problem is rather whether the process should take place or not (i.e., should NickServ identification happen in the first place? see questions on re-NICK above) and when (dinging is OK if close to an event triggered by the user, which if I remember correctly is the case now except for delayed autojoining, if the delay is too long). > 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. Not sure what you are referring to here. Maybe after fully reading bugs and mails, things will get clear, but for now they are rather obscure. Trying anyway: 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? 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? > 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? Not at this point, because I don't know IRC enough, and I'm not using other services bot. What would doing this buy us? I can't answer that now. That said, I think we (at least, I) should rather focus on needs and mechanisms (e.g., such as authentication), and then deal with actual implementations, possibly involving bots (e.g., NickServ for auth). -- Olivier Certner