View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004025 | unreal | ircd | public | 2011-06-22 20:39 | 2015-08-08 16:59 |
| Reporter | LEthaLity | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.9-RC1 | ||||
| Summary | 0004025: multiple @'s in mode strings and their strange results. | ||||
| Description | Couldn't seem to find this bug already existing; but adding an extra @ to a command eg b,e,I totally alters the string, I think InspIRCd strips the second one. | ||||
| Steps To Reproduce | /mode #Channel +b *!*@btcentralplus.com@ Will result in a ban on *!*lplus.com@* Tested and reproduced on b,e,I also | ||||
| 3rd party modules | |||||
|
|
Confirmed, probably bug in clean_ban_mask() + trim_str() functions |
|
|
If you set +b *!<long string>@etcetc the IRCd will shorten the usermask/ident (<long string> is considered the usermask) while still making it match. Ex: *[email protected] becomes *!*[email protected] (from the top of my head). With multiple @'s it's no difference, except that it seems the ircd assumes the last '@' is the nick!ident@host separator... which is probably correct, not sure. In either case, setting a regular ban with multiple @'s makes no sense as it will never match anyway, so does it really matter? :P |
|
|
but btcentralplus.com becoming *!*lplus.com@* isn't correct, yes it won't match, but it would make more sense to ignore the second @ and add the ban as expected eg. *!*@btcentralplus.com |
|
|
How is unrealircd supposed to read your mind? If the ban's not valid, there's no point in supporting it. If, however, it was somehow allowed for usernames or hostname to have `@' in them (which unrealircd prevents from happening at all AFAIK), then there'd be a reason to do something special if there are multiple `@'s in a ban mask. |
|
|
*sigh* Not supporting something would result in "nothing" or an error message... Not a "hey let's just f*^k up what I was given and place an incorrect ban that doesn't match", no? Unreal: /mode #Channel +b *!*@616667F3.CCD77B85.B52B818A.IP@ -[06:56:49]- * LEthaLity sets mode: +b *!*2B818A.IP@* InspIRCd: The same ban will result in -[06:58:02]- * LEthaLity sets mode: +b *!*@616667F3.CCD77B85.B52B818A.IP At least that's not changing what we have given it.. I'm talking about common sense and the expected behaviour, not debating how someone would be stupid enough to add a second @ in the first place.. |
|
|
I must second LEthaLity on this. Unreal should parse from left to right and ignore the second @ since the first @ should delimit the string separating user from host. By RFC1413 a @ cannot be in the username field as it's a token character nor by RFC952 for the hostname field anyway do so why assume the second one is correct?? By doing this you aren't reading minds, you are following established standards. nick -> ! <-> user <-> @ <-> host <ignore extra data> After parsing the banmask, if this leaves the user with an undesired ban, then it is the users responsibility to correct it, not that it matters because any u@h mask with 2 @'s is invalid anyway. |
|
|
I agree it should parse from left to right, current behavior is odd, I agree. If anyone posts a patch to fix this behavior then feel free to do so. Still, when you ask UnrealIRCd to add a ban which will never match, don't be surprised if it adds... an ban which will never match! ;) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-06-22 20:39 | LEthaLity | New Issue | |
| 2011-06-23 10:58 | argvx | Note Added: 0016674 | |
| 2011-06-24 20:54 | syzop | Note Added: 0016675 | |
| 2011-06-26 23:42 | LEthaLity | Note Added: 0016676 | |
| 2011-06-27 04:16 | ohnobinki | Note Added: 0016677 | |
| 2011-06-27 08:01 | LEthaLity | Note Added: 0016678 | |
| 2011-07-12 21:58 | katsklaw | Note Added: 0016682 | |
| 2011-07-12 22:05 | katsklaw | Note Edited: 0016682 | |
| 2011-07-12 22:05 | katsklaw | Note Edited: 0016682 | |
| 2011-07-13 15:08 | katsklaw | Note Edited: 0016682 | |
| 2012-12-15 20:57 | syzop | Note Added: 0017268 | |
| 2012-12-28 17:23 | syzop | Severity | minor => tweak |
| 2015-08-08 16:58 | syzop | Status | new => closed |
| 2015-08-08 16:59 | syzop | Assigned To | => syzop |
| 2015-08-08 16:59 | syzop | Resolution | open => no change required |
