View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005558 | unreal | ircd | public | 2020-02-11 23:54 | 2020-02-12 01:24 |
Reporter | westor | Assigned To | syzop | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 5.0.3 | ||||
Fixed in Version | 5.0.3.1 | ||||
Summary | 0005558: UnrealIRCD doesn't changing the nickname in some cases | ||||
Description | Hello, A user name MrRandom reported that when you connect into a server without join anywhere and stay idle until the network services (atheme + anope) changing your nickname because you didn't identified it seems that services sending the nickname changing notice but the nickname never changed. - Thanks! | ||||
Steps To Reproduce | 1. Connect in a server that you have a register nickname and is protected. 2. Do not identify. 3. Stay idle about 1 minute until services will force to change your nickname. 4. When the services will send you a notice that they changed your nickname check your client status to confirm that is not changed at all. | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
doing /nick <protectednick> -NickServ- This nickname is registered and protected. If it is your -NickServ- nick, type /msg NickServ IDENTIFY password. Otherwise, -NickServ- please choose a different nick. -NickServ- If you do not change within 1 minute, I will change your nick. doing //whois $me <protectednick> is <ident>@<host> * <rlnm> <protectednick> is using modes +iwxzt <protectednick> is connecting from *@<host> <ip> <protectednick> using irc.* <nw> <protectednick> is using a Secure Connection <protectednick> has client certificate fingerprint <fp> <protectednick> has been idle 1min 37secs, signed on Tue Feb 11 23:46:36 2020 <protectednick> End of /WHOIS list. -NickServ- Your nickname is now being changed to <XXXX>-22820 doing //whois $me <protectednick> No such nick/channel <protectednick> End of /WHOIS list. doing /whois on <XXXX>-22820 works. ------------------------ unreal v5.0.1 with patches (5.0.2;5.0.3) anope v2.0.7 |
|
This is confirmed by the official reporter on a network with Atheme (7.2.10-r2) services and by me on anope (2.0.7). |
|
after forced nickchange to <XXXX>-22820, if i join to the chan, thats not visible for the client/user, only to the rest of the users in the chan. |
|
The bad thing here is that it breaks clients, so if the user will join in a channel after all these then the client will not display the joined channel. So i recommend a quick release after that fix, it's a kind of major. |
|
Fixed in git. This bug classifies as major indeed because it breaks clients. Still, I don't think we would need to do a release or an announcement. I mean, this bug is there since 5.0.0 and nobody noticed it apparently. That has to say something about how big of a problem it is. (After all it requires KILL to be on and not to be on the NS access list etc.) Such type of bugs happen more often and they usually don't warrant an immediate release. Another example would be not seeing delayedjoin users PART which is a similar major protocol bug that happened in specific circumstances. That one was fixed in 5.0.3 (and was not the reason that 5.0.3 got released that soon). Also, this particular bug does not have security consequences AFAICT, as any other users see correct nick changes at all times. I could replace the 5.0.3.1 download I suppose, it has only been a few hours. Sort of an in-between. But.. that too can be a bit confusing. |
|
yeah. cuz of autojoin chan and like if you have a registered nick, why wouldn't you identify (you have cert, sasl..) :) |
|
Exactly, that too. Too many mitigating things for this to classify for a rushed release :D But since there have been only been 30 downloads of 5.0.3.1 I have now indeed replaced the download. There won't be an announcement for it though, I will mention it in the 5.0.4 release notes when that happens, as if it was fixed first in 5.0.4. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-02-11 23:54 | westor | New Issue | |
2020-02-11 23:55 | Lord255 | Note Added: 0021307 | |
2020-02-11 23:56 | westor | Note Added: 0021308 | |
2020-02-11 23:59 | Lord255 | Note Added: 0021309 | |
2020-02-11 23:59 | westor | Note Added: 0021310 | |
2020-02-12 01:10 | syzop | Note Added: 0021311 | |
2020-02-12 01:18 | Lord255 | Note Added: 0021312 | |
2020-02-12 01:21 | syzop | Priority | immediate => normal |
2020-02-12 01:24 | syzop | Assigned To | => syzop |
2020-02-12 01:24 | syzop | Status | new => resolved |
2020-02-12 01:24 | syzop | Resolution | open => fixed |
2020-02-12 01:24 | syzop | Fixed in Version | => 5.0.3.1 |
2020-02-12 01:24 | syzop | Note Added: 0021313 |