View Issue Details

IDProjectCategoryView StatusLast Update
0006014unrealircdpublic2021-11-30 06:21
Reporterprogval Assigned Tok4be  
PrioritylowSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product Version6.0.0-rc1 
Summary0006014: MONITOR accepts masks
DescriptionHi,

Not sure if this is really a bug, just a somewhat surprising behavior.
According to the spec <https://ircv3.net/specs/extensions/monitor> "‘target’ MUST be a valid nick", but it doesn't say what to do with invalid targets.

On Unreal 5 (and all other IRCds I could find), "MONITOR + *!*[email protected]" is ignored. However, Unreal 6 replies with:

:My.Little.Server 731 foo :*!*[email protected]
TagsNo tags attached.
3rd party modules

Activities

progval

2021-11-28 20:30

reporter   ~0022213

Oops, sent too soon.

I forgot to mention the mask doesn't seem to be used for matching, so it's not a big deal.

syzop

2021-11-29 17:38

administrator   ~0022216

Totally fine to report it here. It's weird to accept masks (or send them back, uncut). But if it is not used for matching that is good to hear.. then at least it is not a risk :)

syzop

2021-11-29 17:42

administrator   ~0022217

k4be: is this a problem? would it be better to cut it on ! or @ like we did in the WATCH code at some point i guess? or just... keep it as-is since it's no biggy?
Also can you verify that it indeed never matchesor/ uses hosts or wildcards, just want to be sure and am too lazy to read your code today :D

k4be

2021-11-30 01:16

developer   ~0022229

Any invalid nick is not added to the MONITOR list (and this includes one containing '*', '!' or '@'). Only the initial RPL_MONOFFLINE notification is sent back, using only literal case-insensitive comparison via a find_user call. As progval said, the spec does not tell what to do in this case. The only alternative that makes sense is to ignore the request completely.
Current MONITOR behaviour in this regard is actually identical as with WATCH.

syzop

2021-11-30 06:21

administrator   ~0022230

Thanks k4be for confirming it is only treated as a wrong nick.. sending it back and not adding to list, sounds like how it should be.. no change needed.

Issue History

Date Modified Username Field Change
2021-11-28 20:29 progval New Issue
2021-11-28 20:30 progval Note Added: 0022213
2021-11-29 17:38 syzop Note Added: 0022216
2021-11-29 17:38 syzop Assigned To => k4be
2021-11-29 17:38 syzop Status new => assigned
2021-11-29 17:42 syzop Note Added: 0022217
2021-11-30 01:16 k4be Note Added: 0022229
2021-11-30 06:21 syzop Status assigned => closed
2021-11-30 06:21 syzop Resolution open => no change required
2021-11-30 06:21 syzop Note Added: 0022230