[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#51753: ERC switches to channel buffer on reconnect

From: J.P.
Subject: Re: bug#51753: ERC switches to channel buffer on reconnect
Date: Wed, 10 Nov 2021 19:14:29 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Stefan Kangas <stefan@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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]