[Top][All Lists]

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

Re: bug#46777: 28.0.50; ERC: NickServ identification: Prompt for passwor

From: 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 20:59:54 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> 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.

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.

reply via email to

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