From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#29108: 25.3; ERC SASL support Date: Thu, 17 Nov 2022 07:28:57 -0800 Message-ID: <871qq18urq.fsf__41769.2309174285$1668699038$gmane$org@neverwas.me> References: <87h8ud92zl.fsf@gmail.com> <874jx4h6sk.fsf@neverwas.me> <875yhifujk.fsf_-_@neverwas.me> <87edw4swdk.fsf@neverwas.me> <878rljxfxs.fsf@neverwas.me> <87k04m4th8.fsf@neverwas.me> <87o7thlepf.fsf@neverwas.me> <87o7taoohd.fsf@neverwas.me> <87a64unifk.fsf@neverwas.me> <87y1sdk1fg.fsf@neverwas.me> <875yfflzps.fsf@neverwas.me> <877czuks8k.fsf@neverwas.me> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28569"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, bandali@gnu.org To: 29108@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 17 16:30:31 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ovgqV-0007Fi-9k for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Nov 2022 16:30:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ovgq4-0005ue-5e; Thu, 17 Nov 2022 10:30:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ovgq2-0005uE-Oo for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 10:30:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ovgq2-0007VB-Fl for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 10:30:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ovgq2-00024a-Av for bug-gnu-emacs@gnu.org; Thu, 17 Nov 2022 10:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Nov 2022 15:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29108 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 29108-submit@debbugs.gnu.org id=B29108.16686989527890 (code B ref 29108); Thu, 17 Nov 2022 15:30:02 +0000 Original-Received: (at 29108) by debbugs.gnu.org; 17 Nov 2022 15:29:12 +0000 Original-Received: from localhost ([127.0.0.1]:34047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovgpD-00023B-VX for submit@debbugs.gnu.org; Thu, 17 Nov 2022 10:29:12 -0500 Original-Received: from mail-108-mta69.mxroute.com ([136.175.108.69]:39943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ovgpB-00022w-Iv for 29108@debbugs.gnu.org; Thu, 17 Nov 2022 10:29:10 -0500 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta69.mxroute.com (ZoneMTA) with ESMTPSA id 184863526b90006e99.001 for <29108@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 17 Nov 2022 15:29:01 +0000 X-Zone-Loop: 6942393dcfe740fda627662ed678a4f7e755d59ad105 X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qpzx9cAKcNqNXfkLmLtdTdecfOe+hJ4+0z778gj5cxo=; b=Hr2ygWZBIzooJH3XHXmBKZwFyV Yz0tUhl8hBON5M4+cmqEzurLN7PmSHF+X8JMR5kaou6QvjPzXfe5BUFvrRKLAZIpnQ4rZOzzPs3eF 564acbUd8WE1wBYD0LKwqYJsty8QPvUvAtuROCYX4pnWqrCwEp4qyS+OyIWEji6OXOB6kuJzCv1KL 1YowhzNE7ktd4uRa5+0AhB5wvIVdC3vsZNMBhGutOrl2eDe0rUJl8hXLMlhYokICAo4VM8BCL1MJs sxZV7r5g64Vwjk5j8C836STJcXgG3Bdf8Sp/LiWt3kCbNhQeCmSwacUuJtccsTItf68Yuc0NI/C9v TtTPnLoQ==; In-Reply-To: <877czuks8k.fsf@neverwas.me> (J. P.'s message of "Wed, 16 Nov 2022 22:30:35 -0800") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248125 Archived-At: A couple potential UX concerns likely need addressing: 1. Say a user wants to change an SASL option after quitting a successful session. (Maybe they've added a cert fingerprint and want to try out EXTERNAL.) So they set that new option (globally or locally, doesn't matter) and attempt to /reconnect. Unfortunately, the module won't notice the change and will end up reusing the same parameters again. Granted, this isn't the end of the world, especially if the user knows that trying from scratch with a fresh `erc-tls' invocation is the way to go. But we should probably still make it a point to mention this somewhere. 2. Say a user who's normally cloaked is struggling to configure SASL. They manage to connect and obtain their desired nick, but only provisionally (the timeout is usually something like 30 seconds). Unfortunately, if they don't see the warning or can't get their act together before being renicked and autojoined, they'll end up sharing their IP. But what about if they've configured SASL correctly? It's not unheard of for a server to drop a client during registration for reasons unrelated to authentication, like resource pressure. But this module currently only stashes SASL params after making a successful (logical) connection, meaning perfectly good settings might be thrown away. In and of itself, that's arguably fine, but not so much when combined with auto-reconnect timers (which are then forced to rely solely on SASL defaults and whatever entry-point params and global options happen to be in play). Which ultimately leads to provisional nicks and leaked IPs. Luckily, potential remedies appear to exist. One might involve local handler hooks to just drop the connection on all nick-rejection numerics. Another might be adding some conditional reconnect logic to the module-init procedure that only proceeds when SASL options from a previously successful session are safely on the books. BTW, also spotted a small UI issue. Something like this should fix it: diff --git a/lisp/erc/erc-sasl.el b/lisp/erc/erc-sasl.el index d8ef600351..227ca008ad 100644 --- a/lisp/erc/erc-sasl.el +++ b/lisp/erc/erc-sasl.el @@ -347,7 +347,7 @@ erc-sasl--authenticate-handler (s905 . "ERR SASLTOOLONG (credentials too long) %s") (s906 . "ERR_SASLABORTED (authentication aborted) %s") (s907 . "ERR_SASLALREADY (already authenticated) %s") - (s908 . "RPL_SASLMECHS (unsupported mechanism %m) %s"))) + (s908 . "RPL_SASLMECHS (unsupported mechanism: %m) %s"))) (define-erc-module sasl nil "Non-IRCv3 SASL support for ERC. @@ -411,8 +411,9 @@ erc-sasl--destroy (define-erc-response-handler (908) "Handle a RPL_SASLALREADY response." nil (erc-display-message parsed '(notice error) 'active 's908 - '?m (alist-get 'mechanism erc-sasl--options) - '?s (erc-response.contents parsed)) + ?m (alist-get 'mechanism erc-sasl--options) + ?s (string-join (cdr (erc-response.command-args parsed)) + " ")) (erc-sasl--destroy proc)) (cl-defmethod erc--register-connection (&context (erc-sasl-mode (eql t)))