View Issue Details

IDProjectCategoryView StatusLast Update
0005924unrealircdpublic2021-06-25 08:22
ReporterValware Assigned Tosyzop  
PrioritylowSeveritytweakReproducibilityalways
Status closedResolutionopen 
Product Version5.2.0 
Summary0005924: TKL entries sent to other servers from server name instead of SID
Description:irc.valware.uk TKL + Q * OperServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * NickServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * MemoServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * StatServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * ChanServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * Global services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * HostServ services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * BotBot services.valware.uk 0 1623772635 :Reserved for services
:irc.valware.uk TKL + Q * BotServ services.valware.uk 0 1623772635 :Reserved for services

sorry for de self doxx
Steps To Reproduceview S2S traffic upon connect to server
3rd party modules

Relationships

has duplicate 0005923 closedsyzop channel PRIVMSGS sent using nick, everywhere else is UID 

Activities

syzop

2021-06-25 08:17

administrator   ~0022030

Last edited: 2021-06-25 08:22

As mentioned on IRC, this is not a bug. UID/SIDs can be used anywhere a nick/servername is used and vice-versa. This is also explained in https://www.unrealircd.org/docs/Server_protocol:Changes#UID.27s and https://www.unrealircd.org/docs/Server_protocol:User_ID.
To be honest I think the documentation described it accurately each time where it said "can (theoretically) be used at any place where you use a nick name". It says "can", not "must". But you're not the only one missing that. I don't know if you and those others did not read those parts of the documentation at all or just ignored it, possibly watching server protocol over the wire and seeing so much UID/SID drawing their own conclusions of some sort. I don't know. I really did my best to document it correctly. But, failing apparently. I will see if I can add some more bold and underline to the docs to highlight this.
In any case, no need to open up a bug report for every situation where you see a nick or server name.

You said you were writing your own services? Then your find_client() or equivalent function should search by both ID and nick.

Patches are welcome to update existing code, but they should be well tested. A common problem is the following:
1. You change the code to propagate to servers from sendto_server...... parv[1] to client->id
2. Then later on you realize that there is also other code that sends parv[1] to clients. Now this code previously worked fine since parv[1] was always a nick, but now it contains a UID, so clients suddenly get a UID instead of a nick
3. Enjoy how this causes weird issues, including desyncs (since the client has no idea who it really was)
So you have to be careful. You will only see that if you read the entire function and not only the few lines were server propagation happens. So this requires a good look and testing.
Now, IF there is such a parv[] or similar situation then it make sense to first update the code, changing sending of parv[x] to users to xyz->name, then do an unrealircd release, and then only a few releases later fix the code to send SID/UID to servers. This so you don't get desyncs and other weird situations.
I hope the number of such situations are low, though, some code may be very easily updated without issues. Previously, we had to take UnrealIRCd 4.x into account, and it had a lot more of this parv[] stuff. But again.. one would need to check on a case-by-case basis.
Oh, and let me be clear, point 2 from above is a real bug, doing points 1 and 3 are optional :D.

So, yeah, things are not always as simple.

Issue History

Date Modified Username Field Change
2021-06-24 07:18 Valware New Issue
2021-06-25 08:17 syzop Assigned To => syzop
2021-06-25 08:17 syzop Status new => closed
2021-06-25 08:17 syzop Note Added: 0022030
2021-06-25 08:17 syzop Relationship added has duplicate 0005923
2021-06-25 08:19 syzop Note Edited: 0022030
2021-06-25 08:22 syzop Note Edited: 0022030