View Issue Details

IDProjectCategoryView StatusLast Update
0005558unrealircdpublic2020-02-12 01:24
Reporterwestor Assigned Tosyzop  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version5.0.3 
Fixed in Version5.0.3.1 
Summary0005558: UnrealIRCD doesn't changing the nickname in some cases
DescriptionHello,

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 Reproduce1. 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.
TagsNo tags attached.
3rd party modules

Activities

Lord255

2020-02-11 23:55

reporter   ~0021307

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

westor

2020-02-11 23:56

reporter   ~0021308

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

Lord255

2020-02-11 23:59

reporter   ~0021309

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.

westor

2020-02-11 23:59

reporter   ~0021310

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.

syzop

2020-02-12 01:10

administrator   ~0021311

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.

Lord255

2020-02-12 01:18

reporter   ~0021312

yeah. cuz of autojoin chan and like if you have a registered nick, why wouldn't you identify (you have cert, sasl..) :)

syzop

2020-02-12 01:24

administrator   ~0021313

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.

Issue History

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