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#51753: ERC switches to channel buffer on reconnect Date: Wed, 10 Nov 2021 19:14:29 -0800 Message-ID: <877ddfgz8q.fsf__46160.5365084083$1636600524$gmane$org@neverwas.me> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20471"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: 51753@debbugs.gnu.org, emacs-erc@gnu.org, Amin Bandali To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 11 04:15:14 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ml0YT-00052E-DS for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 11 Nov 2021 04:15:13 +0100 Original-Received: from localhost ([::1]:48222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ml0YS-0007uV-0n for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Nov 2021 22:15:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:45286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ml0YI-0007tJ-Tg for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 22:15:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56340) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ml0YI-00070L-Le for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 22:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ml0YI-0005ig-HT for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 22:15: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, 11 Nov 2021 03:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51753 X-GNU-PR-Package: emacs Original-Received: via spool by 51753-submit@debbugs.gnu.org id=B51753.163660048521938 (code B ref 51753); Thu, 11 Nov 2021 03:15:02 +0000 Original-Received: (at 51753) by debbugs.gnu.org; 11 Nov 2021 03:14:45 +0000 Original-Received: from localhost ([127.0.0.1]:39652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0Y1-0005hm-I8 for submit@debbugs.gnu.org; Wed, 10 Nov 2021 22:14:45 -0500 Original-Received: from mail-108-mta144.mxroute.com ([136.175.108.144]:44769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ml0Xw-0005hG-LT for 51753@debbugs.gnu.org; Wed, 10 Nov 2021 22:14:44 -0500 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta144.mxroute.com (ZoneMTA) with ESMTPSA id 17d0cfd61ea0000b55.001 for <51753@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Thu, 11 Nov 2021 03:14:32 +0000 X-Zone-Loop: c66a96115934e4e6ffe5aba249a813e9ba878a1335d7 X-Originating-IP: [149.28.56.236] 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: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=TOvhXXd7VzoKyrABQU2Px9umdwVNueP8XUVCyPr839E=; b=mTeXPuuBJfLKmzGlGZfa4Joia0 f4D45E+Nx024xQ++udhJE7tg0a4dW8GGG6p6PcrBepRreNdwikBkRZ5RpvmdcAAhbXCpyR09nJ8L3 PDKUxQM1DsbqXevGp4t3qXzxvrGUXqh74z2mrPQl5xgj+99v2M1Xv8lEQxAmRslzu7eejhkqH4FmX Zp4Vyqm3iyOymZxij3gHef6M2b4dScx7++f3BD3dyaCjKVhJOhDagbMfYHyBdcGoyR3pXFwU3YLaX /0vOgYkltgYgaKmP64++IkhF7iZUNZYUZL6BFlZlwFeByLDuiJsj1xjCMXd4wSlaYSq4DIVP3oON9 4LtA34/w==; In-Reply-To: (Stefan Kangas's message of "Wed, 10 Nov 2021 07:09:24 -0800") 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:219578 Archived-At: Stefan Kangas writes: > Severity: important > > When ERC reconnects, it switches buffer to the channel buffers. This is > *very* dangerous. Hi Stefan. Any idea if this is a recent phenomenon or more along the lines of traditional behavior, perhaps involving `erc-join-buffer', for example? I ask this mostly out of self interest re commit 17e7cab1507a185d2c493548494abcad6a55d159 Normalize usage of variable erc-server-reconnecting and its followup commit ec9ddd6eaf3f1b118d3ce95a69e1d046166362d3 Deprecate instead of redefine erc-server-reconnecting (both recent and both mine). Regardless, there's a solid chance what you're experiencing is `erc-setup-buffer' related, which comes into play whenever `erc-open' runs. For reconnects, this happens both during `erc-server-reconnect' and again whenever `erc-server-JOIN' runs (for channels you join). It'd also be nice to know how these JOIN replies are being triggered (server-initiated, erc-join.el, manual /join, etc.). With the join module, they'd likely be the result of a JOIN command (request) sent by `erc-autojoin-channels', which runs on 376/422. This matters when trying to pinpoint problematic interplay with the reconnect logic, if such a thing exists. > Consider the situation when the user is about to paste a password and > hit enter with a quick "C-y RET", when all of a sudden the ERC buffer > pops up a fraction of a second before you hit those keys. Now your > password is on IRC. > > At the very least, this behavior should be disabled by default, and > preferably also come with a big warning sign for anyone that intends to > enable it. I don't think many would argue that this behavior isn't at least annoying. While specific scenarios (like accidentally broadcasting creds to a channel) are important to confront, we should also remember to take in the long view whenever possible (IMO). And in doing so, I think we'll find that the many downsides of interfacing with a services bot have over time compelled the IRC world to embrace SASL (part of the IRCv3 initiative) as the preferred means of authentication. Thanks.