From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 12:34:02 2021 Received: (at submit) by debbugs.gnu.org; 25 Feb 2021 17:34:02 +0000 Received: from localhost ([127.0.0.1]:39157 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKWY-0005uE-Es for submit@debbugs.gnu.org; Thu, 25 Feb 2021 12:34:02 -0500 Received: from lists.gnu.org ([209.51.188.17]:50638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKWV-0005to-Bd for submit@debbugs.gnu.org; Thu, 25 Feb 2021 12:34:01 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52252) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFKWV-0000Be-1Y for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2021 12:33:59 -0500 Received: from smtp6-g21.free.fr ([2a01:e0c:1:1599::15]:50674) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFKWT-0004MM-5d for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2021 12:33:58 -0500 Received: from ravel.localnet (unknown [90.118.181.206]) (Authenticated sender: ocert.dev@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id 930EB78032A for ; Thu, 25 Feb 2021 18:33:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1614274434; bh=mM5YnwtlAsp8uz8Pz3JS+HBfIDIYGdVIaPZcgGQtkXE=; h=From:To:Subject:Date:From; b=IgJYN+kyam/UWP3VVidAX11dA1MQRSI49d8AmTap6DoHiH74vq/j/OY3OdtVWbauk 9HNQLXrv1dnP9JYbPInm1om7h7vQJE1SgZY7aXtsSkL2DVm+30P/vWGE9XASTpTBQ4 UZuUF2A0roEXAXm0FZi/ff6sKb+xI12fRf9ws/51VtJ2OFya3K7rwOw8WBY+0WzpKR Y4Xga946uJEKPeucKCF8t4UBRQz4hlZvsmE4deZUibXIAFaueLPrAPFNBrCoKeOFxn 6R7vND5zx/oC2qtByCpeW8fA+UoySosf8QjDc8Ld+Cj0F8YPQULpVECx2WZz4FZk0c Dw2x8VQ3rDRiw== From: Olivier Certner To: bug-gnu-emacs@gnu.org Subject: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Thu, 25 Feb 2021 18:33:53 +0100 Message-ID: <5495728.XOh7uYVVfo@ravel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a01:e0c:1:1599::15; envelope-from=ocert.dev@free.fr; helo=smtp6-g21.free.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) When `erc-prompt-for-nickserv-password' is true, don't ignore the other forms of identification. Instead, process them first, and prompt for the password last. Separate concerns (determination of the nick to use, of the password to use, and actual message sending). Note that the user can be interactively prompted for a password on reception of a Nickserv request, as before (on `erc-prompt-for-nickserv-password'). This is a follow-up to #45340 (see end of discussion there for additional context). Pull request with the single commit to be posted after the bug is open. Changes rebased on master. -- Olivier Certner From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 12:38:49 2021 Received: (at 46777) by debbugs.gnu.org; 25 Feb 2021 17:38:49 +0000 Received: from localhost ([127.0.0.1]:39169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKbB-00061M-Fx for submit@debbugs.gnu.org; Thu, 25 Feb 2021 12:38:49 -0500 Received: from smtp6-g21.free.fr ([212.27.42.6]:59770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKbA-00061E-0a for 46777@debbugs.gnu.org; Thu, 25 Feb 2021 12:38:48 -0500 Received: from ravel.localnet (unknown [90.118.181.206]) (Authenticated sender: ocert.dev@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id CCBD5780344 for <46777@debbugs.gnu.org>; Thu, 25 Feb 2021 18:38:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1614274726; bh=7qYjXbe7GVsXEF0Y7ECombN2rw9SnX4E3eyO2D6xVTw=; h=From:To:Subject:Date:From; b=BgbwGhXHz6LqWI/C59RJ/UVen5TX3v3B7tUTYtqOP4USD0zpKdv5Mb5ls02J5Ke1i 6XJY46TjFRS5P+bVuwsQnIV7/lC3RcRw+nI5whQnxlvJY1xMZKfIERV6/t68RVPEe4 h90YJUxWFgD7IdzgzZDXnkNNmkKBaVjHWVBSPkYsHn33qTib65iWg7hUOBmS5l3MPm VBvy0DuWowjdnlA+sZeS48Ds73vQCMymQ5TYK344zysFAagjuvBzD5VSO6sHSzeyqC q3TpiIDMDOOVBWBv8GZNi/kr0jQ45WksCuQ+XqK31uABZqQKHu+y18Sb18ZW407tjz 7KkSAb1w6ITnA== From: Olivier Certner To: 46777@debbugs.gnu.org Subject: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Thu, 25 Feb 2021 18:38:45 +0100 Message-ID: <2068265.RhTPgMbj8J@ravel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Corresponding "pull request" (just for showing the diff): https://github.com/OlCe2/emacs/pull/2 -- Olivier Certner From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 12:47:40 2021 Received: (at 46777) by debbugs.gnu.org; 25 Feb 2021 17:47:41 +0000 Received: from localhost ([127.0.0.1]:39178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKjk-0006EE-LZ for submit@debbugs.gnu.org; Thu, 25 Feb 2021 12:47:40 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:35183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFKji-0006E1-Oy for 46777@debbugs.gnu.org; Thu, 25 Feb 2021 12:47:39 -0500 Received: by mail-wm1-f51.google.com with SMTP id o16so5611986wmh.0 for <46777@debbugs.gnu.org>; Thu, 25 Feb 2021 09:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=L9c4XAhF7I3O/NzSFREFsrrZ6A0WA4wX6geUcN+Dibc=; b=dbk/4E1hFwoIRNTJeUbJVJSIHxZP+s9SGk18AXIIoVZFfjEXcJdsNE977Z2suJMVV3 Y2o6WbMHTeprCLm/dD35eJPMPu7lgiCCKnHpL0zl6LMiDgzzcViNgTSiaFDTWER3Zf6P +a1RHcHIJTCs3IVCOF6fC/buYigygkFW+GL5Jy9U2jVZo9f5T1SBQJldqnTGckk8VsDE gc6OxqD2NNOLOfEDI54hEgy3IrYM4Qww8T3hlI0ENK9Z5TbOX7VIX9T+78R3Lb4fG9Lq WzJXghztIAY9fmT7/UoVs0riA+RQrv6XeU/AAL0RfgDm5Q7cG4mf9o9ezM2dpUvca8DT pgew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=L9c4XAhF7I3O/NzSFREFsrrZ6A0WA4wX6geUcN+Dibc=; b=dsGXpEX9217Nz4vGWSkOEFP27cj/ntTGjeBVQpeQKEP5zQE7HuVbpXwhrJO49KVlN4 def/iq4Rkoog4nWzOGpbBu69ZEVk3fjJW6d//8QWn3ome0UacJ+f+8olgGO8nX1o6Psi xFfJEQRRiA9BqbKXzbxCmR2P+lCtGuUfx6Dwt99FK7JjI2g4R6XbzJ32bo7PwMQBuJxP kbsaSnu7sjsk/gyoSxic9g+VXhYSegtaJwUvAZyzIf0R93mrlxOPZy0geF0TwM02bgFh xU2eKnNR7nOBilbMNJXKg3/NLebqfp+7HWEdGK0BSI8QxqIsqPIJqd19sqqXS3EPkjrM fguQ== X-Gm-Message-State: AOAM5309T6J3T4DBw2wNd50Ihili8w7MmA/a/kc2i4LNdSeyAX530AhK sDo7wt5Pc0WZzzVyeJoU2OIR+w== X-Google-Smtp-Source: ABdhPJwZZBDxyewiz6QEncQ658ddLloLhmHKM44ZjRv+Eq5w09imqctF4x6z2RTuS94xnbm7jAAQpA== X-Received: by 2002:a1c:5419:: with SMTP id i25mr4400438wmb.166.1614275252920; Thu, 25 Feb 2021 09:47:32 -0800 (PST) Received: from localhost ([2a02:8084:20e2:c380:d15:339e:aa10:60f1]) by smtp.gmail.com with ESMTPSA id a14sm11072708wrg.84.2021.02.25.09.47.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Feb 2021 09:47:32 -0800 (PST) From: "Basil L. Contovounesios" To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <2068265.RhTPgMbj8J@ravel> Date: Thu, 25 Feb 2021 17:47:31 +0000 In-Reply-To: <2068265.RhTPgMbj8J@ravel> (Olivier Certner's message of "Thu, 25 Feb 2021 18:38:45 +0100") Message-ID: <87im6ghwek.fsf@tcd.ie> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Olivier Certner writes: > Corresponding "pull request" (just for showing the diff): > https://github.com/OlCe2/emacs/pull/2 Thanks, but I think it's generally easier/preferred to review patches here if you send them as attachments. See the file CONTRIBUTE. -- Basil From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 13:22:16 2021 Received: (at 46777) by debbugs.gnu.org; 25 Feb 2021 18:22:16 +0000 Received: from localhost ([127.0.0.1]:39227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFLHE-00073M-72 for submit@debbugs.gnu.org; Thu, 25 Feb 2021 13:22:16 -0500 Received: from smtp6-g21.free.fr ([212.27.42.6]:14964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFLH7-000738-Hd for 46777@debbugs.gnu.org; Thu, 25 Feb 2021 13:22:15 -0500 Received: from ravel.localnet (unknown [90.118.181.206]) (Authenticated sender: ocert.dev@free.fr) by smtp6-g21.free.fr (Postfix) with ESMTPSA id BACFF7802B2; Thu, 25 Feb 2021 19:22:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr; s=smtp-20201208; t=1614277328; bh=zEvhJ6aoTbtVSx2wuQVumZMkSvkBxlkblZwABxRTuDg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bF/zBqQVPxdDLMJpQ6WKQ2U3NXveqj2hoFk42xjK0l+3KJ6u02pKhqfHJuePA4JmX c31RimO3kPpng3xnxix4hziKp5lGixidi/4LJ9WPjAStOlUtoEOWaHS3I0ufhDrJxP +HTHSEkwzo0Imf1tMEwusi8I/6WBj0RGvl5myARo71b5HP8LbvFuy+Kp/zvg1oEN0F zL0fuiVw/rLoMKiBl8FTzQGrbewKMAM2SVFPqz469F06Uw/DOPK1iuTSyL7i4d1hKs zTJQwY9NJ7/UVGUi1krWE2NyjQkyfvjMzILF73zLeYpZgLICRo1UEAPmGLdz7G6jT+ ekf0Ztgy84QGw== From: Olivier Certner To: "Basil L. Contovounesios" Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Thu, 25 Feb 2021 19:22:04 +0100 Message-ID: <2033905.uJW0cDvVUg@ravel> In-Reply-To: <87im6ghwek.fsf@tcd.ie> References: <5495728.XOh7uYVVfo@ravel> <2068265.RhTPgMbj8J@ravel> <87im6ghwek.fsf@tcd.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1896953.EnoYUHA41c" Content-Transfer-Encoding: 7Bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --nextPart1896953.EnoYUHA41c Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Sure. Attached. -- Olivier Certner --nextPart1896953.EnoYUHA41c Content-Disposition: attachment; filename="0001-NickServ-identification-Prompt-for-password-last-ove.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-NickServ-identification-Prompt-for-password-last-ove.patch" >From 0b3d0c7a53f4a9d14db8301a8e499bf62cab619a Mon Sep 17 00:00:00 2001 From: Olivier Certner Date: Fri, 5 Feb 2021 15:34:50 +0100 Subject: [PATCH] NickServ identification: Prompt for password last, overall simplifications When `erc-prompt-for-nickserv-password' is true, don't ignore the other forms of identification. Instead, process them first, and prompt for the password last. Separate concerns (determination of the nick to use, of the password to use, and actual message sending). Note that the user can be interactively prompted for a password on reception of a Nickserv request, as before (on `erc-prompt-for-nickserv-password'). * 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'. (erc-nickserv-send-identify): New function containing the sending code, given the nick and password. (erc-nickserv-get-password): Try each password source in turn, in this order: `erc-nickserv-passwords', auth-source (if `erc-use-auth-source-for-nickserv-password' is true), and in the end prompt the user interactively (if `erc-prompt-for-nickserv-password' is true). If one source returns a string, the function returns it, or nil if the string is empty. (erc-nickserv-call-identify-function): Remove. It was necessary as a cumbersome workaround for the fact that the code for password prompting was in the `interactive' form of function `erc-nickserv-identify' before this change. (erc-nickserv-identify-autodetect, erc-nickserv-identify-on-connect) (erc-nickserv-identify-on-nick-change): Call `erc-nickserv-identify' directly (`erc-nickserv-call-identify-function' was removed). For the last two functions, remove the redundant checks on the Nickserv identification flags (additionally, it is doubtful they have any measurable impact on performance). --- etc/NEWS | 14 +++- lisp/erc/erc-services.el | 157 ++++++++++++++++++++++----------------- 2 files changed, 99 insertions(+), 72 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index caa366aaef..3fbf7c6b29 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1528,14 +1528,20 @@ https://www.w3.org/TR/xml/#charsets). Now it rejects such strings. ** erc ---- -*** erc-services.el now supports NickServ passwords from auth-source. +*** NickServ passwords can now be retrieved from auth-source The 'erc-use-auth-source-for-nickserv-password' user option enables querying auth-source for NickServ passwords. To enable this, add the following to your init file: - (setq erc-prompt-for-nickserv-password nil - erc-use-auth-source-for-nickserv-password t) + (setq erc-use-auth-source-for-nickserv-password t) + +*** NickServ identification now prompts for password last +When 'erc-prompt-for-nickserv-password' is true, the user used to be +unconditionally prompted interactively for a password, regardless of +the content of `erc-nickserv-passwords', which was effectively ignored +(same for the new 'erc-use-auth-source-for-nickserv-password'). This +limitation is now removed, and the user is interactively prompted +last, after the other identification methods have run. --- *** The '/ignore' command will now ask for a timeout to stop ignoring the user. diff --git a/lisp/erc/erc-services.el b/lisp/erc/erc-services.el index 9ef8b7f46a..3740e54672 100644 --- a/lisp/erc/erc-services.el +++ b/lisp/erc/erc-services.el @@ -170,9 +170,8 @@ You can also use \\[erc-nickserv-identify-mode] to change modes." (defcustom erc-use-auth-source-for-nickserv-password nil "Query auth-source for a password when identifiying to NickServ. -This option has an no effect if `erc-prompt-for-nickserv-password' -is non-nil, and passwords from `erc-nickserv-passwords' take -precedence." +Passwords from `erc-nickserv-passwords' take precedence. See +function `erc-nickserv-get-password'." :version "28.1" :group 'erc-services :type 'boolean) @@ -400,85 +399,107 @@ password for this nickname, otherwise try to send it automatically." identify-regex (string-match identify-regex msg)) (erc-log "NickServ IDENTIFY request detected") - (erc-nickserv-call-identify-function nick) + (erc-nickserv-identify nick) nil)))) (defun erc-nickserv-identify-on-connect (_server nick) "Identify to Nickserv after the connection to the server is established." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nick))) (defun erc-nickserv-identify-on-nick-change (nick _old-nick) "Identify to Nickserv whenever your nick changes." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nick))) -(defun erc-nickserv-get-password (nickname) - "Return the password for NICKNAME from configured sources. +(defun erc-nickserv-get-password (nick) + "Return the password for NICK from configured sources. +First, a password for NICK is looked up in +`erc-nickserv-passwords'. Then, it is looked up in auth-source +if `erc-use-auth-source-for-nickserv-password' is not nil. +Finally, interactively prompt the user, if +`erc-prompt-for-nickserv-password' is true. -It uses `erc-nickserv-passwords' and additionally auth-source -when `erc-use-auth-source-for-nickserv-password' is not nil." - (or - (when erc-nickserv-passwords - (cdr (assoc nickname - (nth 1 (assoc (erc-network) - erc-nickserv-passwords))))) - (when erc-use-auth-source-for-nickserv-password - (let* ((secret (nth 0 (auth-source-search - :max 1 :require '(:secret) - :host (erc-with-server-buffer erc-session-server) - :port (format ; ensure we have a string - "%s" (erc-with-server-buffer erc-session-port)) - :user nickname)))) - (when secret - (let ((passwd (plist-get secret :secret))) - (if (functionp passwd) (funcall passwd) passwd))))))) - -(defun erc-nickserv-call-identify-function (nickname) - "Call `erc-nickserv-identify'. -Either call it interactively or run it with NICKNAME's password, -depending on the value of `erc-prompt-for-nickserv-password'." - (if erc-prompt-for-nickserv-password - (call-interactively 'erc-nickserv-identify) - (erc-nickserv-identify (erc-nickserv-get-password nickname)))) +As soon as some source returns a password, the sequence of +lookups stops and this function returns it (or returns nil if it +is empty). Otherwise, no corresponding password was found, and +it returns nil." + (let (network server port) + ;; Fill in local vars, switching to the server buffer once only + (erc-with-server-buffer + (setq network erc-network + server erc-session-server + port erc-session-port)) + (let ((ret + (or + (when erc-nickserv-passwords + (cdr (assoc nick + (cl-second (assoc network + erc-nickserv-passwords))))) + (when erc-use-auth-source-for-nickserv-password + (let ((secret (cl-first (auth-source-search + :max 1 :require '(:secret) + :host server + ;; Ensure a string for :port + :port (format "%s" port) + :user nick)))) + (when secret + (let ((passwd (plist-get secret :secret))) + (if (functionp passwd) (funcall passwd) passwd))))) + (when erc-prompt-for-nickserv-password + (read-passwd + (format "NickServ password for %s on %s (RET to cancel): " + nick network)))))) + (when (and ret (not (string= ret ""))) + ret)))) (defvar erc-auto-discard-away) -;;;###autoload -(defun erc-nickserv-identify (password) +(defun erc-nickserv-send-identify (nick password) "Send an \"identify \" message to NickServ. -When called interactively, read the password using `read-passwd'." +Returns t if the message could be sent, nil otherwise." + (let* ((erc-auto-discard-away nil) + (network (erc-network)) + (nickserv-info (assoc network erc-nickserv-alist)) + (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) + "NickServ")) + (identify-word (or (erc-nickserv-alist-ident-keyword + nil nickserv-info) + "IDENTIFY")) + (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) + (concat nick " ") + "")) + (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) + "PRIVMSG"))) + (erc-message msgtype + (concat nickserv " " identify-word " " nick password)))) + +;;;###autoload +(defun erc-nickserv-identify (&optional nick) + "Identify to NickServ immediately. +Identification will either use NICK or the current nick if not +provided, and some password obtained through +`erc-nickserv-get-password' (which see). If no password can be +found, an error is reported trough `erc-error'. + +Interactively, the user will be prompted for NICK, an empty +string meaning to default to the current nick. + +Returns t if the identify message could be sent, nil otherwise." (interactive - (list (read-passwd - (format "NickServ password for %s on %s (RET to cancel): " - (erc-current-nick) - (or (and (erc-network) - (symbol-name (erc-network))) - "Unknown network"))))) - (when (and password (not (string= "" password))) - (let* ((erc-auto-discard-away nil) - (network (erc-network)) - (nickserv-info (assoc network erc-nickserv-alist)) - (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) - "NickServ")) - (identify-word (or (erc-nickserv-alist-ident-keyword - nil nickserv-info) - "IDENTIFY")) - (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) - (concat (erc-current-nick) " ") - "")) - (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) - "PRIVMSG"))) - (erc-message msgtype - (concat nickserv " " identify-word " " nick password))))) + (list + (read-from-minibuffer "Nickname: " nil nil nil + 'erc-nick-history-list (erc-current-nick)))) + (unless (and nick (not (string= nick ""))) + (setq nick (erc-current-nick))) + (let ((password (erc-nickserv-get-password nick))) + (if password + (erc-nickserv-send-identify nick password) + (erc-error "Cannot find a password for nickname %s" + nick) + nil))) (provide 'erc-services) -- 2.30.0 --nextPart1896953.EnoYUHA41c-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 04:23:41 2021 Received: (at control) by debbugs.gnu.org; 26 Feb 2021 09:23:41 +0000 Received: from localhost ([127.0.0.1]:40302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFZLZ-00019w-6w for submit@debbugs.gnu.org; Fri, 26 Feb 2021 04:23:41 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFZLW-00019e-50 for control@debbugs.gnu.org; Fri, 26 Feb 2021 04:23:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=TeSIt0ZpFsmYWRAw2pndiDYYdcJnhM1nB1bsBEUoqSg=; b=VxfCyxqtBCLTkNc1FBUhQv3shg 6hPHxDyBIs1cI10yDij4nNHIQmOTzxulPwXrHHoCjpNs+cfmuCaOqxy0I/rUo1Px7XkChr6Kx/2+Z vg96bVXsrkOHMtSKdEcFaaQSB9uJ9BM/Ujd0+HNOMMvCNTCSd2ncGQmAurTc60Pu7cFs=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lFZLN-0000hM-Ql for control@debbugs.gnu.org; Fri, 26 Feb 2021 10:23:31 +0100 Date: Fri, 26 Feb 2021 10:23:26 +0100 Message-Id: <871rd3mbch.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #46777 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 46777 + patch quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 46777 + patch quit From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 07 22:23:51 2021 Received: (at 46777) by debbugs.gnu.org; 8 Jun 2021 02:23:51 +0000 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 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 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] From: "J.P." To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> Date: Mon, 07 Jun 2021 19:23:39 -0700 In-Reply-To: <5495728.XOh7uYVVfo@ravel> (Olivier Certner's message of "Thu, 25 Feb 2021 18:33:53 +0100") Message-ID: <878s3l6qms.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 09 09:31:07 2021 Received: (at 46777) by debbugs.gnu.org; 9 Jun 2021 13:31:07 +0000 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 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 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== From: Olivier Certner To: "J.P." Subject: Re: 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> In-Reply-To: <878s3l6qms.fsf@neverwas.me> References: <5495728.XOh7uYVVfo@ravel> <878s3l6qms.fsf@neverwas.me> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 10 00:00:11 2021 Received: (at 46777) by debbugs.gnu.org; 10 Jun 2021 04:00:11 +0000 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 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 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] From: "J.P." To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <878s3l6qms.fsf@neverwas.me> <1960033.R0FQcr2YjX@ravel> Date: Wed, 09 Jun 2021 20:59:54 -0700 In-Reply-To: <1960033.R0FQcr2YjX@ravel> (Olivier Certner's message of "Wed, 09 Jun 2021 15:30:55 +0200") Message-ID: <87tum6nzd1.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 06 10:58:42 2021 Received: (at 46777) by debbugs.gnu.org; 6 Jul 2021 14:58:42 +0000 Received: from localhost ([127.0.0.1]:49681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0mX3-0006xq-E0 for submit@debbugs.gnu.org; Tue, 06 Jul 2021 10:58:42 -0400 Received: from smtp5-g21.free.fr ([212.27.42.5]:58850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0mQj-0006oJ-Mi for 46777@debbugs.gnu.org; Tue, 06 Jul 2021 10:52:10 -0400 Received: from ravel.localnet (unknown [2.15.208.149]) (Authenticated sender: ocert.dev@free.fr) by smtp5-g21.free.fr (Postfix) with ESMTPSA id D55A1600CC for <46777@debbugs.gnu.org>; Tue, 6 Jul 2021 16:52:06 +0200 (CEST) From: Olivier Certner To: 46777@debbugs.gnu.org Subject: Updated patch Date: Tue, 06 Jul 2021 16:52:06 +0200 Message-ID: <4764688.dQ8sKJKaaQ@ravel> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart7347825.Em7K3W7WdZ" Content-Transfer-Encoding: 7Bit X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 46777 X-Mailman-Approved-At: Tue, 06 Jul 2021 10:58:37 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) This is a multi-part message in MIME format. --nextPart7347825.Em7K3W7WdZ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Patch slightly edited (commit message, doc text) and rebased on top of a recent 'master'. Ready to apply. Easy to backport to 27 as well. -- Olivier Certner --nextPart7347825.Em7K3W7WdZ Content-Disposition: attachment; filename="0001-ERC-NickServ-Prompt-for-password-last-overall-simpli.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-ERC-NickServ-Prompt-for-password-last-overall-simpli.patch" >From 70d13beadc2c2d6dbb36e277ab47fa6cc1ae3903 Mon Sep 17 00:00:00 2001 From: Olivier Certner Date: Fri, 5 Feb 2021 15:34:50 +0100 Subject: [PATCH] ERC: NickServ: Prompt for password last, overall simplifications (bug#46777) When `erc-prompt-for-nickserv-password' is true, don't ignore the other forms of identification. Instead, process them first, and prompt for the password last. Separate concerns (determination of the nick to use, of the password to use, and actual message sending). Note that the user can be interactively prompted for a password on reception of a Nickserv request, as before (on `erc-prompt-for-nickserv-password'). * 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'. (erc-nickserv-send-identify): New function containing the sending code, given the nick and password. (erc-nickserv-get-password): Try each password source in turn, in this order: `erc-nickserv-passwords', auth-source (if `erc-use-auth-source-for-nickserv-password' is true), and in the end prompt the user interactively (if `erc-prompt-for-nickserv-password' is true). If one source returns a string, the function returns it, or nil if the string is empty. (erc-nickserv-call-identify-function): Remove. It was necessary as a cumbersome workaround for the fact that the code for password prompting was in the `interactive' form of function `erc-nickserv-identify' before this change. (erc-nickserv-identify-autodetect, erc-nickserv-identify-on-connect) (erc-nickserv-identify-on-nick-change): Call `erc-nickserv-identify' directly (`erc-nickserv-call-identify-function' was removed). For the last two functions, remove the redundant checks on the Nickserv identification flags (additionally, it is doubtful they have any measurable impact on performance). --- etc/NEWS | 14 +++- lisp/erc/erc-services.el | 157 ++++++++++++++++++++++----------------- 2 files changed, 99 insertions(+), 72 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index c3eaf5fcbb..af2aa21905 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1948,14 +1948,20 @@ https://www.w3.org/TR/xml/#charsets). Now it rejects such strings. ** erc ---- -*** erc-services.el now supports NickServ passwords from auth-source. +*** NickServ passwords can now be retrieved from auth-source The 'erc-use-auth-source-for-nickserv-password' user option enables querying auth-source for NickServ passwords. To enable this, add the following to your init file: - (setq erc-prompt-for-nickserv-password nil - erc-use-auth-source-for-nickserv-password t) + (setq erc-use-auth-source-for-nickserv-password t) + +*** NickServ identification now prompts for password last +When 'erc-prompt-for-nickserv-password' is true, the user used to be +unconditionally prompted interactively for a password, regardless of +the content of `erc-nickserv-passwords', which was effectively ignored +(same for the new 'erc-use-auth-source-for-nickserv-password'). This +limitation is now removed, and the user is interactively prompted +last, after the other identification methods have run. --- *** The '/ignore' command will now ask for a timeout to stop ignoring the user. diff --git a/lisp/erc/erc-services.el b/lisp/erc/erc-services.el index 61006e0c02..4233b4a322 100644 --- a/lisp/erc/erc-services.el +++ b/lisp/erc/erc-services.el @@ -169,9 +169,8 @@ erc-prompt-for-nickserv-password (defcustom erc-use-auth-source-for-nickserv-password nil "Query auth-source for a password when identifiying to NickServ. -This option has an no effect if `erc-prompt-for-nickserv-password' -is non-nil, and passwords from `erc-nickserv-passwords' take -precedence." +Passwords from `erc-nickserv-passwords' take precedence. See +function `erc-nickserv-get-password'." :version "28.1" :type 'boolean) @@ -405,85 +404,107 @@ erc-nickserv-identify-autodetect identify-regex (string-match identify-regex msg)) (erc-log "NickServ IDENTIFY request detected") - (erc-nickserv-call-identify-function nick) + (erc-nickserv-identify nick) nil)))) (defun erc-nickserv-identify-on-connect (_server nick) "Identify to Nickserv after the connection to the server is established." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nick))) (defun erc-nickserv-identify-on-nick-change (nick _old-nick) "Identify to Nickserv whenever your nick changes." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nick))) -(defun erc-nickserv-get-password (nickname) - "Return the password for NICKNAME from configured sources. +(defun erc-nickserv-get-password (nick) + "Return the password for NICK from configured sources. +First, a password for NICK is looked up in +`erc-nickserv-passwords'. Then, it is looked up in auth-source +if `erc-use-auth-source-for-nickserv-password' is not nil. +Finally, interactively prompt the user, if +`erc-prompt-for-nickserv-password' is true. -It uses `erc-nickserv-passwords' and additionally auth-source -when `erc-use-auth-source-for-nickserv-password' is not nil." - (or - (when erc-nickserv-passwords - (cdr (assoc nickname - (nth 1 (assoc (erc-network) - erc-nickserv-passwords))))) - (when erc-use-auth-source-for-nickserv-password - (let* ((secret (nth 0 (auth-source-search - :max 1 :require '(:secret) - :host (erc-with-server-buffer erc-session-server) - :port (format ; ensure we have a string - "%s" (erc-with-server-buffer erc-session-port)) - :user nickname)))) - (when secret - (let ((passwd (plist-get secret :secret))) - (if (functionp passwd) (funcall passwd) passwd))))))) - -(defun erc-nickserv-call-identify-function (nickname) - "Call `erc-nickserv-identify'. -Either call it interactively or run it with NICKNAME's password, -depending on the value of `erc-prompt-for-nickserv-password'." - (if erc-prompt-for-nickserv-password - (call-interactively 'erc-nickserv-identify) - (erc-nickserv-identify (erc-nickserv-get-password nickname)))) +As soon as some source returns a password, the sequence of +lookups stops and this function returns it (or returns nil if it +is empty). Otherwise, no corresponding password was found, and +it returns nil." + (let (network server port) + ;; Fill in local vars, switching to the server buffer once only + (erc-with-server-buffer + (setq network erc-network + server erc-session-server + port erc-session-port)) + (let ((ret + (or + (when erc-nickserv-passwords + (cdr (assoc nick + (cl-second (assoc network + erc-nickserv-passwords))))) + (when erc-use-auth-source-for-nickserv-password + (let ((secret (cl-first (auth-source-search + :max 1 :require '(:secret) + :host server + ;; Ensure a string for :port + :port (format "%s" port) + :user nick)))) + (when secret + (let ((passwd (plist-get secret :secret))) + (if (functionp passwd) (funcall passwd) passwd))))) + (when erc-prompt-for-nickserv-password + (read-passwd + (format "NickServ password for %s on %s (RET to cancel): " + nick network)))))) + (when (and ret (not (string= ret ""))) + ret)))) (defvar erc-auto-discard-away) -;;;###autoload -(defun erc-nickserv-identify (password) +(defun erc-nickserv-send-identify (nick password) "Send an \"identify \" message to NickServ. -When called interactively, read the password using `read-passwd'." +Returns t if the message could be sent, nil otherwise." + (let* ((erc-auto-discard-away nil) + (network (erc-network)) + (nickserv-info (assoc network erc-nickserv-alist)) + (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) + "NickServ")) + (identify-word (or (erc-nickserv-alist-ident-keyword + nil nickserv-info) + "IDENTIFY")) + (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) + (concat nick " ") + "")) + (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) + "PRIVMSG"))) + (erc-message msgtype + (concat nickserv " " identify-word " " nick password)))) + +;;;###autoload +(defun erc-nickserv-identify (&optional nick) + "Identify to NickServ immediately. +Identification will either use NICK or the current nick if not +provided, and some password obtained through +`erc-nickserv-get-password' (which see). If no password can be +found, an error is reported trough `erc-error'. + +Interactively, the user will be prompted for NICK, an empty +string meaning to default to the current nick. + +Returns t if the identify message could be sent, nil otherwise." (interactive - (list (read-passwd - (format "NickServ password for %s on %s (RET to cancel): " - (erc-current-nick) - (or (and (erc-network) - (symbol-name (erc-network))) - "Unknown network"))))) - (when (and password (not (string= "" password))) - (let* ((erc-auto-discard-away nil) - (network (erc-network)) - (nickserv-info (assoc network erc-nickserv-alist)) - (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) - "NickServ")) - (identify-word (or (erc-nickserv-alist-ident-keyword - nil nickserv-info) - "IDENTIFY")) - (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) - (concat (erc-current-nick) " ") - "")) - (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) - "PRIVMSG"))) - (erc-message msgtype - (concat nickserv " " identify-word " " nick password))))) + (list + (read-from-minibuffer "Nickname: " nil nil nil + 'erc-nick-history-list (erc-current-nick)))) + (unless (and nick (not (string= nick ""))) + (setq nick (erc-current-nick))) + (let ((password (erc-nickserv-get-password nick))) + (if password + (erc-nickserv-send-identify nick password) + (erc-error "Cannot find a password for nickname %s" + nick) + nil))) (provide 'erc-services) -- 2.30.0 --nextPart7347825.Em7K3W7WdZ-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 22 08:30:07 2021 Received: (at 46777) by debbugs.gnu.org; 22 Jul 2021 12:30:07 +0000 Received: from localhost ([127.0.0.1]:39609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6Xq3-0001Dh-5V for submit@debbugs.gnu.org; Thu, 22 Jul 2021 08:30:07 -0400 Received: from quimby.gnus.org ([95.216.78.240]:54334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m6Xq2-00016u-0Q for 46777@debbugs.gnu.org; Thu, 22 Jul 2021 08:30:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=lEHr0NUlxZ2YqKgoqP2O1lXW2Jc3tyrv18OdXwCNlzA=; b=ItsGsZKZL+sQ96Gdu0jL7UxEWD AX0g475ThMHGhnpjj5H93XZ7hIFwPLM4CpjMEP5LId/MfkoBu2jkfGhvGnyVp7zWqNDF2IAfelCRc E9oD6BOwAhqthgI/zRgoJkkz/JjGEur8+homR7LSJZfg+xnYf02Icbi4i+e4TzN9NmO8=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m6Xpt-0002EQ-47; Thu, 22 Jul 2021 14:29:59 +0200 From: Lars Ingebrigtsen To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> X-Now-Playing: Hilary Woods's _Birthmarks_: "Cleansing Ritual" Date: Thu, 22 Jul 2021 14:29:56 +0200 In-Reply-To: <4764688.dQ8sKJKaaQ@ravel> (Olivier Certner's message of "Tue, 06 Jul 2021 16:52:06 +0200") Message-ID: <87pmvaleez.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Olivier Certner writes: > Patch slightly edited (commit message, doc text) and rebased on top of a > recent 'master'. Ready to apply. Easy to backport to 27 as well. Amin, have you found time to look at this patch from Olivier (and the other three (I think) patches)? If you can't find the time, I can examine them and get them applied. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: Amin Bandali , 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Olivier Certner writes: > Patch slightly edited (commit message, doc text) and rebased on top of a > recent 'master'. Ready to apply. Easy to backport to 27 as well. Amin, have you found time to look at this patch from Olivier (and the other three (I think) patches)? If you can't find the time, I can examine them and get them applied. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 26 03:39:53 2021 Received: (at 46777) by debbugs.gnu.org; 26 Jul 2021 07:39:53 +0000 Received: from localhost ([127.0.0.1]:49855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7vDM-0007Nk-UE for submit@debbugs.gnu.org; Mon, 26 Jul 2021 03:39:53 -0400 Received: from mail-109-mta53.mxroute.com ([136.175.109.53]:46551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m7vDK-0007NX-Ur for 46777@debbugs.gnu.org; Mon, 26 Jul 2021 03:39:51 -0400 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-109-mta53.mxroute.com (ZoneMTA) with ESMTPSA id 17ae1c157da000ae11.002 for <46777@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Mon, 26 Jul 2021 07:39:42 +0000 X-Zone-Loop: 086700e2218bdd28e733cf3f05e2786d04d481a80bb4 X-Originating-IP: [149.28.56.236] From: "J.P." To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> Date: Mon, 26 Jul 2021 00:39:39 -0700 In-Reply-To: <4764688.dQ8sKJKaaQ@ravel> (Olivier Certner's message of "Tue, 06 Jul 2021 16:52:06 +0200") Message-ID: <87sg01jzgk.fsf_-_@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: masked@neverwas.me X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, FROM_HAS_DN=0, RCPT_COUNT_THREE=0, TO_DN_SOME=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, NEURAL_SPAM=0, MID_RHS_MATCH_FROM=0] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Olivier Certner 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 08:27:35 2021 Received: (at 46777) by debbugs.gnu.org; 30 Jul 2021 12:27:36 +0000 Received: from localhost ([127.0.0.1]:59305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Rbz-0004Qw-NH for submit@debbugs.gnu.org; Fri, 30 Jul 2021 08:27:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Rby-0004Qj-71 for 46777@debbugs.gnu.org; Fri, 30 Jul 2021 08:27:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37222) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9Rbr-00014o-VT; Fri, 30 Jul 2021 08:27:27 -0400 Received: from cpe00fc8de16db3-cm00fc8de16db0.cpe.net.cable.rogers.com ([99.228.88.100]:60108 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9Rbr-0007R9-RB; Fri, 30 Jul 2021 08:27:27 -0400 From: Amin Bandali To: Lars Ingebrigtsen Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87pmvaleez.fsf_-_@gnus.org> Date: Fri, 30 Jul 2021 08:27:26 -0400 In-Reply-To: <87pmvaleez.fsf_-_@gnus.org> Message-ID: <87im0saswh.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: Olivier Certner , 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Lars, all, Lars Ingebrigtsen writes: > Olivier Certner writes: > >> Patch slightly edited (commit message, doc text) and rebased on top of a >> recent 'master'. Ready to apply. Easy to backport to 27 as well. > > Amin, have you found time to look at this patch from Olivier (and the > other three (I think) patches)? If you can't find the time, I can > examine them and get them applied. Apologies for my slow reply and absence. I haven't been well for a few weeks, and didn't have the time and energy to do much outside of work. Thankfully I am better now, and expect to be able to review Olivier's patches and hopefully get them applied in the coming days, starting tomorrow. If not, I'll let you all know so you could review and apply them, thanks! From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 30 08:43:58 2021 Received: (at 46777) by debbugs.gnu.org; 30 Jul 2021 12:43:58 +0000 Received: from localhost ([127.0.0.1]:59365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Rrq-0004tm-Fg for submit@debbugs.gnu.org; Fri, 30 Jul 2021 08:43:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9Rro-0004tY-SJ for 46777@debbugs.gnu.org; Fri, 30 Jul 2021 08:43:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=QsqTtDSi2kvmKCNaZnd9pNbzMSedW2WjhZMZn3LnXy4=; b=tF4ZqUF0kSYIol1f2+/P2ftoog 5t8mpvvRjdiqWC5YeCuarbHD+rXcn54gv5tbs8+U7X02iHA7qBhqJp90WKK2BRmOox6sqxMBrCu9Z ORKjiuk3qGXUZBpwko9KCJ7IetcJUXuDWfeQc9MEjmKXjn2ceVPXd+ERZMMtFa8COJf4=; Received: from 2.149.45.105.tmi.telenormobil.no ([2.149.45.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m9Rrg-0007VM-6Y; Fri, 30 Jul 2021 14:43:50 +0200 From: Lars Ingebrigtsen To: Amin Bandali Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87pmvaleez.fsf_-_@gnus.org> <87im0saswh.fsf@gnu.org> Date: Fri, 30 Jul 2021 14:43:46 +0200 In-Reply-To: <87im0saswh.fsf@gnu.org> (Amin Bandali's message of "Fri, 30 Jul 2021 08:27:26 -0400") Message-ID: <877dh8m0ot.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Amin Bandali writes: > Apologies for my slow reply and absence. I haven't been well for a few > weeks, and didn't have the time and energy to do much outside of work. > Thankfully I am better now, and expect to be able to [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: Olivier Certner , 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Amin Bandali writes: > Apologies for my slow reply and absence. I haven't been well for a few > weeks, and didn't have the time and energy to do much outside of work. > Thankfully I am better now, and expect to be able to review Olivier's > patches and hopefully get them applied in the coming days, starting > tomorrow. If not, I'll let you all know so you could review and apply > them, thanks! Great! (Well, not great that you haven't been feeling well, but that you're better. :-)) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 14 05:21:12 2021 Received: (at 46777) by debbugs.gnu.org; 14 Sep 2021 09:21:12 +0000 Received: from localhost ([127.0.0.1]:47526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ4cp-0006wl-SK for submit@debbugs.gnu.org; Tue, 14 Sep 2021 05:21:12 -0400 Received: from mail-108-mta107.mxroute.com ([136.175.108.107]:43933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQ4cl-0006wH-5n for 46777@debbugs.gnu.org; Tue, 14 Sep 2021 05:21:10 -0400 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta107.mxroute.com (ZoneMTA) with ESMTPSA id 17be39c100600074ba.002 for <46777@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 14 Sep 2021 09:21:00 +0000 X-Zone-Loop: c38ccf63718163f4956517023374ce29997ed54b452b X-Originating-IP: [149.28.56.236] From: "J.P." To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> Date: Tue, 14 Sep 2021 02:20:55 -0700 In-Reply-To: <87sg01jzgk.fsf_-_@neverwas.me> (J. P.'s message of "Mon, 26 Jul 2021 00:39:39 -0700") Message-ID: <87ee9r4io8.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-AuthUser: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: Amin Bandali , emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain "J.P." writes: > If that's a realistic concern, perhaps you should consider keeping the > password param in its original position for the sake of compatibility. Recent discussions have left me with the impression that at least one consequential voice may be harboring reservations about the proposed interface change to `erc-nickserv-identify'. I'd like to offer some thoughts towards salvaging (at a minimum) the "prompting as a fallback" portion of this patch, which I feel may be helpful to new users. As a side note, the few changes that appear motivated mostly by promoting a separation of concerns seem at worst benign and otherwise potentially beneficial beyond maintenance matters (IMO). For example, adding a helper, like the proposed `erc-nickserv-send-identify', to encapsulate the actual request-making may improve this module's utility as a traditional library. (A few bots may even appreciate that.) Regarding the perceived minor bone of contention, my instincts favor the bold move, as usual. But that's contingent on all things being equal, which they likely aren't here (because passwords), meaning progressive attitudes may have to take a back seat. So as a compromise, how about an ugly chimera like the one in the attached example? --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0000-NOT-A-PATCH-discussion-example.diff >From 8ede558f8b7885e97bced96f5d06206ecb23a719 Mon Sep 17 00:00:00 2001 From: "F. Jason Park" Date: Mon, 13 Sep 2021 22:24:57 -0700 Subject: NOT A PATCH Rebased atop commit 25ebb9374bdadf66153727831fc7ff131c8cf299 Author: Stefan Kangas Date: Tue Sep 14 07:55:56 2021 +0200 ; More minor docfixes found by checkdoc for easier am-ing, should anyone want to inspect the changes in-tree. Also, one tweak to the commit message isn't shown in the diff below but has to do with no longer removing erc-nickserv-call-identity-function. In general, I'm pretty much indifferent about preserving a revised rendition of that function as a disembodied wrapper for erc-nickserv-identify. On the one hand, anyone desperate/resourceful enough to have sought out the original (way back whenever) should be capable of taking a little churn in stride. That said, if I were enumerating things to delete from ERC, I'm not sure that'd make the top ten. Olivier Certner (1): ERC: NickServ: Prompt for password last, overall simplifications (bug#46777) etc/NEWS | 13 ++- lisp/erc/erc-services.el | 168 +++++++++++++++++++++++---------------- 2 files changed, 108 insertions(+), 73 deletions(-) Interdiff: diff --git a/lisp/erc/erc-services.el b/lisp/erc/erc-services.el index 4233b4a322..adb3f521cd 100644 --- a/lisp/erc/erc-services.el +++ b/lisp/erc/erc-services.el @@ -404,20 +404,20 @@ erc-nickserv-identify-autodetect identify-regex (string-match identify-regex msg)) (erc-log "NickServ IDENTIFY request detected") - (erc-nickserv-identify nick) + (erc-nickserv-identify nil nick) nil)))) (defun erc-nickserv-identify-on-connect (_server nick) "Identify to Nickserv after the connection to the server is established." (unless (and (eq erc-nickserv-identify-mode 'both) (erc-nickserv-alist-regexp (erc-network))) - (erc-nickserv-identify nick))) + (erc-nickserv-identify nil nick))) (defun erc-nickserv-identify-on-nick-change (nick _old-nick) "Identify to Nickserv whenever your nick changes." (unless (and (eq erc-nickserv-identify-mode 'both) (erc-nickserv-alist-regexp (erc-network))) - (erc-nickserv-identify nick))) + (erc-nickserv-identify nil nick))) (defun erc-nickserv-get-password (nick) "Return the password for NICK from configured sources. @@ -481,8 +481,13 @@ erc-nickserv-send-identify (erc-message msgtype (concat nickserv " " identify-word " " nick password)))) +(defun erc-nickserv-call-identify-function (nickname) + "Call `erc-nickserv-identify' with NICKNAME." + (declare (obsolete erc-nickserv-identify "28.1")) + (erc-nickserv-identify nil nickname)) + ;;;###autoload -(defun erc-nickserv-identify (&optional nick) +(defun erc-nickserv-identify (&optional password nick) "Identify to NickServ immediately. Identification will either use NICK or the current nick if not provided, and some password obtained through @@ -495,16 +500,18 @@ erc-nickserv-identify Returns t if the identify message could be sent, nil otherwise." (interactive (list + nil (read-from-minibuffer "Nickname: " nil nil nil 'erc-nick-history-list (erc-current-nick)))) (unless (and nick (not (string= nick ""))) (setq nick (erc-current-nick))) - (let ((password (erc-nickserv-get-password nick))) - (if password - (erc-nickserv-send-identify nick password) - (erc-error "Cannot find a password for nickname %s" - nick) - nil))) + (unless password + (setq password (erc-nickserv-get-password nick))) + (if password + (erc-nickserv-send-identify nick password) + (erc-error "Cannot find a password for nickname %s" + nick) + nil)) (provide 'erc-services) -- 2.31.1 --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-ERC-NickServ-Prompt-for-password-last-overall-simpli.patch >From 99a110fa6d2f2be7b86bbf7a0c84089f19a1f584 Mon Sep 17 00:00:00 2001 From: Olivier Certner Date: Fri, 5 Feb 2021 15:34:50 +0100 Subject: [PATCH 1/1] ERC: NickServ: Prompt for password last, overall simplifications (bug#46777) When `erc-prompt-for-nickserv-password' is true, don't ignore the other forms of identification. Instead, process them first, and prompt for the password last. Separate concerns (determination of the nick to use, of the password to use, and actual message sending). Note that the user can be interactively prompted for a password on reception of a Nickserv request, as before (on `erc-prompt-for-nickserv-password'). * 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'. (erc-nickserv-send-identify): New function containing the sending code, given the nick and password. (erc-nickserv-get-password): Try each password source in turn, in this order: `erc-nickserv-passwords', auth-source (if `erc-use-auth-source-for-nickserv-password' is true), and in the end prompt the user interactively (if `erc-prompt-for-nickserv-password' is true). If one source returns a string, the function returns it, or nil if the string is empty. (erc-nickserv-call-identify-function): Retained for compatibility but deprecated for simplicity. Prefer invoking erc-nickserv-identify directly instead. (erc-nickserv-identify-autodetect, erc-nickserv-identify-on-connect) (erc-nickserv-identify-on-nick-change): Call `erc-nickserv-identify' directly (`erc-nickserv-call-identify-function' was removed). For the last two functions, remove the redundant checks on the Nickserv identification flags (additionally, it is doubtful they have any measurable impact on performance). --- etc/NEWS | 13 ++- lisp/erc/erc-services.el | 168 +++++++++++++++++++++++---------------- 2 files changed, 108 insertions(+), 73 deletions(-) diff --git a/etc/NEWS b/etc/NEWS index d4f4c81f89..f9f14ea68f 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -2618,13 +2618,20 @@ Interactively, 'C-u C-c C-o' triggers this new optional behavior. ** ERC --- -*** erc-services.el now supports NickServ passwords from auth-source. +*** NickServ passwords can now be retrieved from auth-source The 'erc-use-auth-source-for-nickserv-password' user option enables querying auth-source for NickServ passwords. To enable this, add the following to your init file: - (setq erc-prompt-for-nickserv-password nil - erc-use-auth-source-for-nickserv-password t) + (setq erc-use-auth-source-for-nickserv-password t) + +*** NickServ identification now prompts for password last +When 'erc-prompt-for-nickserv-password' is true, the user used to be +unconditionally prompted interactively for a password, regardless of +the content of `erc-nickserv-passwords', which was effectively ignored +(same for the new 'erc-use-auth-source-for-nickserv-password'). This +limitation is now removed, and the user is interactively prompted +last, after the other identification methods have run. --- *** The '/ignore' command will now ask for a timeout to stop ignoring the user. diff --git a/lisp/erc/erc-services.el b/lisp/erc/erc-services.el index 61006e0c02..adb3f521cd 100644 --- a/lisp/erc/erc-services.el +++ b/lisp/erc/erc-services.el @@ -169,9 +169,8 @@ erc-prompt-for-nickserv-password (defcustom erc-use-auth-source-for-nickserv-password nil "Query auth-source for a password when identifiying to NickServ. -This option has an no effect if `erc-prompt-for-nickserv-password' -is non-nil, and passwords from `erc-nickserv-passwords' take -precedence." +Passwords from `erc-nickserv-passwords' take precedence. See +function `erc-nickserv-get-password'." :version "28.1" :type 'boolean) @@ -405,85 +404,114 @@ erc-nickserv-identify-autodetect identify-regex (string-match identify-regex msg)) (erc-log "NickServ IDENTIFY request detected") - (erc-nickserv-call-identify-function nick) + (erc-nickserv-identify nil nick) nil)))) (defun erc-nickserv-identify-on-connect (_server nick) "Identify to Nickserv after the connection to the server is established." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nil nick))) (defun erc-nickserv-identify-on-nick-change (nick _old-nick) "Identify to Nickserv whenever your nick changes." - (unless (or (and (null erc-nickserv-passwords) - (null erc-prompt-for-nickserv-password) - (null erc-use-auth-source-for-nickserv-password)) - (and (eq erc-nickserv-identify-mode 'both) - (erc-nickserv-alist-regexp (erc-network)))) - (erc-nickserv-call-identify-function nick))) - -(defun erc-nickserv-get-password (nickname) - "Return the password for NICKNAME from configured sources. - -It uses `erc-nickserv-passwords' and additionally auth-source -when `erc-use-auth-source-for-nickserv-password' is not nil." - (or - (when erc-nickserv-passwords - (cdr (assoc nickname - (nth 1 (assoc (erc-network) - erc-nickserv-passwords))))) - (when erc-use-auth-source-for-nickserv-password - (let* ((secret (nth 0 (auth-source-search - :max 1 :require '(:secret) - :host (erc-with-server-buffer erc-session-server) - :port (format ; ensure we have a string - "%s" (erc-with-server-buffer erc-session-port)) - :user nickname)))) - (when secret - (let ((passwd (plist-get secret :secret))) - (if (functionp passwd) (funcall passwd) passwd))))))) - -(defun erc-nickserv-call-identify-function (nickname) - "Call `erc-nickserv-identify'. -Either call it interactively or run it with NICKNAME's password, -depending on the value of `erc-prompt-for-nickserv-password'." - (if erc-prompt-for-nickserv-password - (call-interactively 'erc-nickserv-identify) - (erc-nickserv-identify (erc-nickserv-get-password nickname)))) + (unless (and (eq erc-nickserv-identify-mode 'both) + (erc-nickserv-alist-regexp (erc-network))) + (erc-nickserv-identify nil nick))) + +(defun erc-nickserv-get-password (nick) + "Return the password for NICK from configured sources. +First, a password for NICK is looked up in +`erc-nickserv-passwords'. Then, it is looked up in auth-source +if `erc-use-auth-source-for-nickserv-password' is not nil. +Finally, interactively prompt the user, if +`erc-prompt-for-nickserv-password' is true. + +As soon as some source returns a password, the sequence of +lookups stops and this function returns it (or returns nil if it +is empty). Otherwise, no corresponding password was found, and +it returns nil." + (let (network server port) + ;; Fill in local vars, switching to the server buffer once only + (erc-with-server-buffer + (setq network erc-network + server erc-session-server + port erc-session-port)) + (let ((ret + (or + (when erc-nickserv-passwords + (cdr (assoc nick + (cl-second (assoc network + erc-nickserv-passwords))))) + (when erc-use-auth-source-for-nickserv-password + (let ((secret (cl-first (auth-source-search + :max 1 :require '(:secret) + :host server + ;; Ensure a string for :port + :port (format "%s" port) + :user nick)))) + (when secret + (let ((passwd (plist-get secret :secret))) + (if (functionp passwd) (funcall passwd) passwd))))) + (when erc-prompt-for-nickserv-password + (read-passwd + (format "NickServ password for %s on %s (RET to cancel): " + nick network)))))) + (when (and ret (not (string= ret ""))) + ret)))) (defvar erc-auto-discard-away) -;;;###autoload -(defun erc-nickserv-identify (password) +(defun erc-nickserv-send-identify (nick password) "Send an \"identify \" message to NickServ. -When called interactively, read the password using `read-passwd'." +Returns t if the message could be sent, nil otherwise." + (let* ((erc-auto-discard-away nil) + (network (erc-network)) + (nickserv-info (assoc network erc-nickserv-alist)) + (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) + "NickServ")) + (identify-word (or (erc-nickserv-alist-ident-keyword + nil nickserv-info) + "IDENTIFY")) + (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) + (concat nick " ") + "")) + (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) + "PRIVMSG"))) + (erc-message msgtype + (concat nickserv " " identify-word " " nick password)))) + +(defun erc-nickserv-call-identify-function (nickname) + "Call `erc-nickserv-identify' with NICKNAME." + (declare (obsolete erc-nickserv-identify "28.1")) + (erc-nickserv-identify nil nickname)) + +;;;###autoload +(defun erc-nickserv-identify (&optional password nick) + "Identify to NickServ immediately. +Identification will either use NICK or the current nick if not +provided, and some password obtained through +`erc-nickserv-get-password' (which see). If no password can be +found, an error is reported trough `erc-error'. + +Interactively, the user will be prompted for NICK, an empty +string meaning to default to the current nick. + +Returns t if the identify message could be sent, nil otherwise." (interactive - (list (read-passwd - (format "NickServ password for %s on %s (RET to cancel): " - (erc-current-nick) - (or (and (erc-network) - (symbol-name (erc-network))) - "Unknown network"))))) - (when (and password (not (string= "" password))) - (let* ((erc-auto-discard-away nil) - (network (erc-network)) - (nickserv-info (assoc network erc-nickserv-alist)) - (nickserv (or (erc-nickserv-alist-nickserv nil nickserv-info) - "NickServ")) - (identify-word (or (erc-nickserv-alist-ident-keyword - nil nickserv-info) - "IDENTIFY")) - (nick (if (erc-nickserv-alist-use-nick-p nil nickserv-info) - (concat (erc-current-nick) " ") - "")) - (msgtype (or (erc-nickserv-alist-ident-command nil nickserv-info) - "PRIVMSG"))) - (erc-message msgtype - (concat nickserv " " identify-word " " nick password))))) + (list + nil + (read-from-minibuffer "Nickname: " nil nil nil + 'erc-nick-history-list (erc-current-nick)))) + (unless (and nick (not (string= nick ""))) + (setq nick (erc-current-nick))) + (unless password + (setq password (erc-nickserv-get-password nick))) + (if password + (erc-nickserv-send-identify nick password) + (erc-error "Cannot find a password for nickname %s" + nick) + nil)) (provide 'erc-services) -- 2.31.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 01:30:30 2021 Received: (at 46777) by debbugs.gnu.org; 16 Sep 2021 05:30:30 +0000 Received: from localhost ([127.0.0.1]:53602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQjyg-00063Q-2e for submit@debbugs.gnu.org; Thu, 16 Sep 2021 01:30:30 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58002) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQjyd-00063C-1H for 46777@debbugs.gnu.org; Thu, 16 Sep 2021 01:30:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:40096) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQjyW-0000i7-4F; Thu, 16 Sep 2021 01:30:20 -0400 Received: from [2607:fea8:3fdf:f2d9:7081:5e69:80c:403f] (port=52046 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQjyV-0007zP-Um; Thu, 16 Sep 2021 01:30:20 -0400 From: Amin Bandali To: "J.P." , Olivier Certner , Lars Ingebrigtsen Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> <87ee9r4io8.fsf@neverwas.me> Date: Thu, 16 Sep 2021 01:30:18 -0400 In-Reply-To: <87ee9r4io8.fsf@neverwas.me> Message-ID: <87v931cck5.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: emacs-erc@gnu.org, 46777@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi all, J.P. writes: > "J.P." writes: > >> If that's a realistic concern, perhaps you should consider keeping the >> password param in its original position for the sake of compatibility. > > Recent discussions have left me with the impression that at least one > consequential voice may be harboring reservations about the proposed > interface change to `erc-nickserv-identify'. I'd like to offer some > thoughts towards salvaging (at a minimum) the "prompting as a fallback" > portion of this patch, which I feel may be helpful to new users. > > As a side note, the few changes that appear motivated mostly by > promoting a separation of concerns seem at worst benign and otherwise > potentially beneficial beyond maintenance matters (IMO). For example, > adding a helper, like the proposed `erc-nickserv-send-identify', to > encapsulate the actual request-making may improve this module's utility > as a traditional library. (A few bots may even appreciate that.) > > Regarding the perceived minor bone of contention, my instincts favor the > bold move, as usual. But that's contingent on all things being equal, > which they likely aren't here (because passwords), meaning progressive > attitudes may have to take a back seat. So as a compromise, how about an > ugly chimera like the one in the attached example? After a closer look, I am indeed hesitant about merging the original patch, since it changes the interface of `erc-nickserv-identify' -- a function as old as time, as far as ERC is concerned, and likely in use by many -- especially since it deals with passwords. Instead, I would prefer one of the following approaches: 1. change the function's arguments in a backwards-compatible way (i.e. by adding new &optional args as needed), and ignore the arg we don't need anymore (the password in this case, and make sure we don't accidentally expose it instead of a nick); 2. gradually phase out the function if we must: either declare it obsolete and make it a wrapper around a new function with the desired API (I did this recently for one of Olivier's patches for erc-track) (this might very well involve option 1 as well), and remove the function at some later point after some major releases of Emacs; or 3. save the backward-incompatible interface change for a major ERC version bump. We could do one or a mix of the above three options gradually, giving users enough time and notice to adapt, and avoid putting them at risk. For this case, option 1 seems straightforward to do, but so does 2. >From a quick look at J.P.'s revised version of Olivier's patch, it looks quite favourable to me, in its preserving backward compatibility in erc-nickserv-identify's interface and obsoleting (rather than deleting) erc-nickserv-call-identify-function and making it a wrapper around erc-nickserv-identify, and could probably be merged with few minor tweaks. J.P., Olivier, Lars, thoughts? From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 08:42:54 2021 Received: (at 46777) by debbugs.gnu.org; 16 Sep 2021 12:42:54 +0000 Received: from localhost ([127.0.0.1]:54086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQqj7-0004w2-Q1 for submit@debbugs.gnu.org; Thu, 16 Sep 2021 08:42:53 -0400 Received: from quimby.gnus.org ([95.216.78.240]:36028) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQqj5-0004vp-Jx for 46777@debbugs.gnu.org; Thu, 16 Sep 2021 08:42:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References: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=3oSQ7qlvVOqTdY3RZ0Cgj/wCtgMRDmzYzzAg6iH4Fso=; b=Jdko9Bt0nkDWquvfi4VV8i3yjE VXdNw37eqakB2ipsUgxKoSe3/h6xY5gIYcTIM9zG/VcgSSYlyYMAvV42w5GtxXnSxi8lyv8/yU6+e 99ZOK34kl/28pnIp9eM8uGMkBOK3tCgzahAOFCR3FE0qn36yg3MeSQ04hoN+J49uuAiY=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQqiw-0002o6-IU; Thu, 16 Sep 2021 14:42:44 +0200 From: Lars Ingebrigtsen To: Amin Bandali Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> <87ee9r4io8.fsf@neverwas.me> <87v931cck5.fsf@gnu.org> Date: Thu, 16 Sep 2021 14:42:42 +0200 In-Reply-To: <87v931cck5.fsf@gnu.org> (Amin Bandali's message of "Thu, 16 Sep 2021 01:30:18 -0400") Message-ID: <87ilz03d4t.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Amin Bandali writes: > 2. gradually phase out the function if we must: either declare it > obsolete and make it a wrapper around a new function with the > desired API This is usually the way to handle things like this, and it looks like the right solution here, too. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: Olivier Certner , emacs-erc@gnu.org, 46777@debbugs.gnu.org, "J.P." X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Amin Bandali writes: > 2. gradually phase out the function if we must: either declare it > obsolete and make it a wrapper around a new function with the > desired API This is usually the way to handle things like this, and it looks like the right solution here, too. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 16 22:17:14 2021 Received: (at 46777) by debbugs.gnu.org; 17 Sep 2021 02:17:14 +0000 Received: from localhost ([127.0.0.1]:58061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR3RC-0000b5-9O for submit@debbugs.gnu.org; Thu, 16 Sep 2021 22:17:14 -0400 Received: from mail-108-mta233.mxroute.com ([136.175.108.233]:36391) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR3R8-0000aq-ND for 46777@debbugs.gnu.org; Thu, 16 Sep 2021 22:17:13 -0400 Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta233.mxroute.com (ZoneMTA) with ESMTPSA id 17bf18af8d900074ba.002 for <46777@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 17 Sep 2021 02:17:01 +0000 X-Zone-Loop: 70995ecc494ee884e5d041cde985d284a240a3c0e306 X-Originating-IP: [149.28.56.236] From: "J.P." To: Amin Bandali Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> <87ee9r4io8.fsf@neverwas.me> <87v931cck5.fsf@gnu.org> Date: Thu, 16 Sep 2021 19:16:54 -0700 In-Reply-To: <87v931cck5.fsf@gnu.org> (Amin Bandali's message of "Thu, 16 Sep 2021 01:30:18 -0400") Message-ID: <87tuikymi1.fsf@neverwas.me> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: masked@neverwas.me X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46777 Cc: Olivier Certner , emacs-erc@gnu.org, 46777@debbugs.gnu.org, Lars Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Amin Bandali writes: > 1. change the function's arguments in a backwards-compatible way > (i.e. by adding new &optional args as needed), and ignore the > arg we don't need anymore (the password in this case, and > make sure we don't accidentally expose it instead of a nick); I guess ignoring the password arg means some folks currently using this entry point in lisp code may have to call `erc-nickserv-send-identify' directly instead, depending on their needs. Works for me, but if that's the plan, I don't think the version I sent fits the bill entirely. > From a quick look at J.P.'s revised version of Olivier's patch, it > looks quite favourable to me Um, that was mostly me trying out my bandali impersonation (blasphemous, I know). From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 00:45:36 2021 Received: (at 46777-done) by debbugs.gnu.org; 17 Sep 2021 04:45:36 +0000 Received: from localhost ([127.0.0.1]:58259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR5kl-0004QP-TD for submit@debbugs.gnu.org; Fri, 17 Sep 2021 00:45:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR5ki-0004QB-F1 for 46777-done@debbugs.gnu.org; Fri, 17 Sep 2021 00:45:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50414) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mR5kb-0006ZB-HG; Fri, 17 Sep 2021 00:45:25 -0400 Received: from [2607:fea8:3fdf:f2d9:a4cf:ca3d:20e1:2f59] (port=53154 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mR5kb-0001MT-4q; Fri, 17 Sep 2021 00:45:25 -0400 From: Amin Bandali To: 46777-done@debbugs.gnu.org Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <4764688.dQ8sKJKaaQ@ravel> <87sg01jzgk.fsf_-_@neverwas.me> <87ee9r4io8.fsf@neverwas.me> <87v931cck5.fsf@gnu.org> <87ilz03d4t.fsf@gnus.org> Date: Fri, 17 Sep 2021 00:45:24 -0400 In-Reply-To: <87ilz03d4t.fsf@gnus.org> Message-ID: <87a6kbn72z.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777-done Cc: Olivier Certner , emacs-erc@gnu.org, Lars Ingebrigtsen , "J.P." X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi all, Lars Ingebrigtsen writes: > Amin Bandali writes: > >> 2. gradually phase out the function if we must: either declare it >> obsolete and make it a wrapper around a new function with the >> desired API > > This is usually the way to handle things like this, and it looks like > the right solution here, too. Thanks, sounds good. * * * J.P. writes: > Amin Bandali writes: > >> 1. change the function's arguments in a backwards-compatible way >> (i.e. by adding new &optional args as needed), and ignore the >> arg we don't need anymore (the password in this case, and >> make sure we don't accidentally expose it instead of a nick); > > I guess ignoring the password arg means some folks currently using this > entry point in lisp code may have to call `erc-nickserv-send-identify' > directly instead, depending on their needs. Works for me, but if that's > the plan, I don't think the version I sent fits the bill entirely. Right. I think your *not* ignoring the password here is actually more familiar and desirable, and I prefer it over what I'd suggested. :) >> From a quick look at J.P.'s revised version of Olivier's patch, it >> looks quite favourable to me > > Um, that was mostly me trying out my bandali impersonation (blasphemous, > I know). Ha, you give me too much credit. :) Okay so having tested and reviewed J.P.'s revised patch, it looks good to me; so I went ahead and merged it with some minor tweaks, including listing J.P. as co-author: https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6eb114a42922af18818dce7317238e0af776958 Thank you all for your help and bearing with me until I finally got around to this. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 17 03:57:45 2021 Received: (at 46777) by debbugs.gnu.org; 17 Sep 2021 07:57:45 +0000 Received: from localhost ([127.0.0.1]:58382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR8ki-00018i-UL for submit@debbugs.gnu.org; Fri, 17 Sep 2021 03:57:45 -0400 Received: from smtp2-g21.free.fr ([212.27.42.2]:36580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mR8kc-00018V-U0 for 46777@debbugs.gnu.org; Fri, 17 Sep 2021 03:57:43 -0400 Received: from ravel.localnet (unknown [90.118.180.28]) (Authenticated sender: ocert.dev@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 23ABF200401; Fri, 17 Sep 2021 09:57:30 +0200 (CEST) From: Olivier Certner To: 46777@debbugs.gnu.org, bandali@gnu.org, jp@neverwas.me Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications Date: Fri, 17 Sep 2021 09:57:29 +0200 Message-ID: <2703107.iZhWRnD58j@ravel> In-Reply-To: <87a6kbn72z.fsf@gnu.org> References: <5495728.XOh7uYVVfo@ravel> <87ilz03d4t.fsf@gnus.org> <87a6kbn72z.fsf@gnu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 46777 Cc: larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.4 (/) Hi all, Sorry for not having much time to respond, and thanks for having handled the compatibility concern through proposals 1 & 2, which I agree with. In particular, it is best that PASSWORD remains the first parameter to `erc- nickserv-identify', for compatibility but practical use also , since the nick is normally already set when this function is called (non-interactively). The only thing I might have done differently is deleting `erc-nickserv-call- identify-function' instead of obsoleting it since, contrary to `erc-nickserv- identify', I don't think people would use it directly (the name sounds too much "internal"; I may be wrong on its actual use, though). But your approach is the most prudent one. I'll try to hang around in #erc and respond to your mails a bit more quickly, at least for matters that do not take much time. Thanks, Olivier From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 19 11:26:36 2021 Received: (at 46777) by debbugs.gnu.org; 19 Sep 2021 15:26:36 +0000 Received: from localhost ([127.0.0.1]:39561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRyi8-0004wN-MZ for submit@debbugs.gnu.org; Sun, 19 Sep 2021 11:26:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mRyi7-0004wB-GV for 46777@debbugs.gnu.org; Sun, 19 Sep 2021 11:26:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55558) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mRyi1-0001tQ-FQ; Sun, 19 Sep 2021 11:26:25 -0400 Received: from [2607:fea8:3fdf:f2d9:2c21:f874:901c:eb1c] (port=46954 helo=langa) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mRyhx-00044s-SQ; Sun, 19 Sep 2021 11:26:25 -0400 From: Amin Bandali To: Olivier Certner Subject: Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications References: <5495728.XOh7uYVVfo@ravel> <87ilz03d4t.fsf@gnus.org> <87a6kbn72z.fsf@gnu.org> <2703107.iZhWRnD58j@ravel> Date: Sun, 19 Sep 2021 11:26:20 -0400 In-Reply-To: <2703107.iZhWRnD58j@ravel> Message-ID: <87k0jc4meb.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 46777 Cc: larsi@gnus.org, 46777@debbugs.gnu.org, jp@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Hi Olivier, Olivier Certner writes: > Hi all, > > Sorry for not having much time to respond, and thanks for having handled the > compatibility concern through proposals 1 & 2, which I agree with. In > particular, it is best that PASSWORD remains the first parameter to `erc- > nickserv-identify', for compatibility but practical use also , since the nick > is normally already set when this function is called (non-interactively). > > The only thing I might have done differently is deleting `erc-nickserv-call- > identify-function' instead of obsoleting it since, contrary to `erc-nickserv- > identify', I don't think people would use it directly (the name sounds too > much "internal"; I may be wrong on its actual use, though). But your approach > is the most prudent one. No worries, and thanks. Yeah we probably could have indeed deleted `erc-nickserv-call-identify-function', but decided to play it safe(r) and keep it for now. :) > I'll try to hang around in #erc and respond to your mails a bit more quickly, > at least for matters that do not take much time. > > Thanks, > Olivier Thanks! -amin From unknown Sat Jun 14 19:02:52 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 18 Oct 2021 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator