GNU bug report logs - #51753
ERC switches to channel buffer on reconnect

Previous Next

Full log

Message #8 received at 51753 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51753 <at> debbugs.gnu.org, emacs-erc <at> gnu.org, Amin Bandali <bandali <at> gnu.org>
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Wed, 10 Nov 2021 19:14:29 -0800

Stefan Kangas <stefan <at> marxist.se> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.