mIRC Home    About    Download    Register    News    Help

Page 1 of 2 1 2 >
Topic Options
#260243 - 20/03/17 08:28 PM Duplicated ban detection
NoMiaus Offline
Mostly harmless

Registered: 20/03/17
Posts: 1
Bug when using mIRC 7.47 and the latest UnrealIRCd version.
1. /mode #Channel +b ~r:xyz
2. /mode #Channel +b ~R:xyz
3. Only the last ban set is shown on the ban list window. I've to detele the second ban added to see the first ban added.

Top
#260244 - 20/03/17 11:36 PM Re: Duplicated ban detection [Re: NoMiaus]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2110
Loc: New Mexico Tech
Hmm, that'd be an interesting one to fix. Ban masks are expected to be case-insensitive, and UnrealIRCd decided to started adding case-sensitive flags to case-insensitive ban masks.

I'm tempted to say this is a bug with UnrealIRCd. They -should- fix it on their end. I'm curious how other clients handle this.
_________________________
doiní things a particle can

Top
#260245 - 21/03/17 09:47 AM Re: Duplicated ban detection [Re: NoMiaus]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Thanks for your post. There seem to be two issues with UnrealIRCD's banlist changes here:

1) The ban list is meant to consist of non-case-sensitive addresses. So this will break case-insensitive handling throughout mIRC of anywhere that these addresses are used both by mIRC and scripts.

2) The "r:" prefix character will break use of these addresses if a client/script assumes that they consist of nick!user@host.

Basically, the ban list cannot be treated as a list of addresses any longer.

Top
#260246 - 21/03/17 11:01 AM Re: Duplicated ban detection [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2110
Loc: New Mexico Tech
Of note, Charybdis (and ircd-seven aka freenode-seven), also permits flags and extraneous info in banmasks. Here are some examples.

nick!user@host$#redirect-channel
$x:nick!user@host#gecos
$r:gecos
$a:account
$~a
$j:#borrow_from_our_banlist

$x:raccoon!fuzzy@woodland.critter.net#I'm?a?little?teapot.$#you_are_banned_go_away

... but in every instance these are case-insensitive.
_________________________
doiní things a particle can

Top
#260247 - 21/03/17 12:53 PM Re: Duplicated ban detection [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Thanks for the clarification. Would you know if each ircd uses a different method for formatting banmasks? Or is there an agreed format? Even so, case-sensitive masks would require special handling, so a numeric 005 token would be needed to identify networks that use them.

Top
#260248 - 23/03/17 03:54 AM Re: Duplicated ban detection [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2110
Loc: New Mexico Tech
In the Charybdis family tree of IRCd's (which is a fork from Ratbox, la Hybrid) they call this extension EXTBAN.

Code:
:hobana.freenode.net 005 Raccoon EXTBAN=$,ajrxz 

-> Server: help extban
-
extban MODE <channel> <+|-><b|q|e|I> $[~]<type>[:<data>]
extban  
extban Extended bans (ban conditionals) allow different checks than the usual
extban nick!user@host or nick!user@ip match to determine whether someone should
extban be banned, quieted, exempted or invited.
extban  
extban Extended bans are of the form $[~]<type>[:<data>]. The <type> is one
extban character (case insensitive) and determines the type of match. Most types
extban allow or require an extra field <data>. If the tilde (~) is present, the
extban result of the comparison will be negated, unless the ban is invalid in which
extban case it will never match. Invalid bans are ones where <data> is missing but
extban required or where <data> is otherwise invalid as noted below.
extban  
extban Unless noted below, all types can be used with +b, +q, +e and +I.
extban  
extban  extb Type  - DESCRIPTION
extban ------------------------------------------------------------------------
extban      $a     - Matches all logged in users
extban   $a:<mask> - Matches users logged in with a username matching the mask
extban               (* and ? wildcards)
extban   $c:<chan> - Matches users who are on the given channel; this is only
extban               valid if the channel exists and is not +s or +p. (The ops
extban               of the channel the ban is on cannot necessarily see whether
extban               the user is in the target channel, so it should not
extban               influence whether they can join either.)
extban      $o     - Matches opers (most useful with +I)
extban   $r:<mask> - Matches users with a realname (gecos) matching the mask
extban               (* and ? wildcards); this can only be used with +b and +q
extban   $s:<mask> - matches users connected to a server matching the mask
extban               (* and ? wildcards); this can only be used with +b and +q
extban   $j:<chan> - matches users who are or are not banned from a specified
extban               channel
extban   $x:<mask> - Bans all users with matching nick!user@host#gecos
extban      $z     - Matches all SSL users
extban  
extban End of /HELP.

I understand this help may be missing one or two.

Also, there have been no breaks or faults in mIRC for years and years, and nobody honestly expects you to add support for these. I don't think any client scripting language automatically does. I mean, maybe $a:<account> and $a and $~a would be doable. Seems a bit far out there.
_________________________
doiní things a particle can

Top
#260249 - 23/03/17 02:53 PM Re: Duplicated ban detection [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Thanks, that really helps. I am sure I have seen the EXTBAN token before but never needed to cater for it in any specific way.

The help reply you listed states that the type character is case-insensitive on freenode. I cannot see a way of supporting case-sensitive type characters on UnrealIRCd without breaking the ban/except/invex/quiet lists on other networks, since users can issue /modes using different cases for both the type and address on case-insensitive networks.

UnrealIRCd would need to add another numeric 005 token or EXTBAN flag to identify that it uses case-sensitive type characters. A client/script would then have to split the address at the : character and perform a case-sensitive comparison on the type and a case-insensitive comparison on the address.

Top
#260250 - 23/03/17 03:45 PM Re: Duplicated ban detection [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 778
Loc: The Netherlands
I suppose that a simple workaround would be to check for presence of both the uppercase and lowercase variant of any letters in the EXTBAN= token. UnrealIRCd would have both 'r' and 'R', which would never be the case on a network that treats them as case-insensitive. Not that I'm advocating supporting all these weird UnrealIRCd features..
_________________________
Saturn, QuakeNet staff

Top
#260251 - 23/03/17 04:10 PM Re: Duplicated ban detection [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Yes, I was considering that. It seems like a reasonable assumption, as long as a network never sends type characters that it has not listed in the EXTBAN - which should be the case.

Top
#260252 - 23/03/17 04:34 PM Re: Duplicated ban detection [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2110
Loc: New Mexico Tech
LOL. "Should be the case."

I learned that many/most of these IRCDs have their 005 hard coded like an MOTD. Freenode disabled MONITOR about a year ago and still leaves it in their 005. It's static decoration, and not actually pulling from a config file. crazy

But yeah, I came to the same conclusion as both you did. Check for case alternation in the 005 flags.
_________________________
doiní things a particle can

Top
#260253 - 23/03/17 05:13 PM Re: Duplicated ban detection [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Right. Just when you think you've figured it all out, along comes:

-> card.freenode.net MODE #thisisatest +b ~R:xyz
<- :user!nick@host MODE #thisisatest +b *!*@~R:xyz

Whereas on UnreadlIRCd:

-> irc1.unrealircd.org MODE #thisisatest +b ~R:xyz
<- :user!nick@host MODE #thisisatest +b ~R:xyz

Not too sure what freenode is doing there.

Update: A little more testing on UnrealIRCd shows that it allows:

-> irc1.unrealircd.org MODE #thisisatest +b *!abc@~r:def.org
<- :user!nick@host MODE #thisisatest +b *!abc@~r:def.org

-> irc1.unrealircd.org MODE #thisisatest +b ~r:*!~r:abc@~r:def.org
<- :user!nick@host MODE #thisisatest +b ~r:*!~r:abc@~r:def.org

So the $[~]<type>[:<data>] format can appear anywhere inside an address and more than once.

Update: I've implemented the case-sensitive/case-insenstive dual-comparison split based on the first : in the address. This will only be enabled for networks that contain two different cases of the same character in EXTBAN. This will be in the next beta.

Top
#260255 - 23/03/17 08:32 PM Re: Duplicated ban detection [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 778
Loc: The Netherlands
Well, the EXTBAN prefix on FreeNode is '$', not '~'. Also, are you sure that UnrealIRCd actually interprets those non-prefix occurrences as extended bans and not simply as part of the ban address mask?
_________________________
Saturn, QuakeNet staff

Top
#260256 - 23/03/17 09:27 PM Re: Duplicated ban detection [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Yup, you're right. I was assuming that : wouldn't be allowed as part of a hostname but that depends on the server, IPv6, etc. So looking for the first : will not be enough. In order to check for a type prefix, mIRC will have to check that the prefix character specified in the EXTBAN is at the start of the address and only then look for the : character.

Update: Drats. Looking at this document on the UnrealIRCd website, it says that you can stack extended bans (see bottom of page). So looking for the first : will not be enough. An IRC client will have to scan through all stacked type prefixes ~q:~c: to make sure it has found the whole of the case-sensitive section of the address. This is assuming all servers implement this the same way.

Top
#260257 - 23/03/17 10:51 PM Re: Duplicated ban detection [Re: Khaled]
Raccoon Offline
Hoopy frood

Registered: 18/02/03
Posts: 2110
Loc: New Mexico Tech
Not all EXTBANs on Freenode will contain a ':' colon, only those that carry parameter data with it. And though extban flags can't be stacked in Freenode, a forwarding '$#channel' can amend any ban, and colon can be used in those channel names as well as IPv6 hosts.

Code:
MODE +b $a          ... ban all registered users.
MODE +b $~a         ... ban all nonregistered users.
MODE +b $a$#c:olon  ... send registered users to channel #c:olon
MODE +b $z          ... ban all SSL users.
MODE +b $~z         ... ban all non-SSL users.
MODE +b $~z$#bu:tt  ... send non-SSL users to channel #bu:tt
_________________________
doiní things a particle can

Top
#260267 - 24/03/17 01:45 PM Re: Duplicated ban detection [Re: Raccoon]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Well, this is getting increasingly complicated and the odds are that I will implement an approximation to how different ircds parse these lines, which might work in some cases but not all.

One solution to all of this is to just avoid performing comparisons on these addresses. The original issue is that mIRC is not seeing all of the addresses in the list. This is because mIRC is maintaining/synchronizing its own internal lists when it sees mode numerics, to avoid excessive /mode requests to the server when channel central is used. This is what requires address comparisons.

I will remove this feature so that mIRC no longer needs to maintain internal ban/except/invex/quiet lists and instead requests them every time you use channel central. That seems to be the only practical solution at this time.

This will not solve everything - the auto-unban feature needs to compare addresses in various situations. However, I can make it case-sensitive and the odds are low that someone will use different case text when adding/removing bans. If they do, the worst that can happen is that mIRC will fail to remove a ban at some point.

Top
#260268 - 24/03/17 02:21 PM Re: Duplicated ban detection [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 778
Loc: The Netherlands
That sounds reasonable but what about $ibl etc then though?
_________________________
Saturn, QuakeNet staff

Top
#260269 - 24/03/17 02:40 PM Re: Duplicated ban detection [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
These would return the most recently looked up list. And .ibl/etc. would return $true/$inmode/$false as usual, however this would be reset to $false the moment a new mode is seen.

Top
#260270 - 24/03/17 03:04 PM Re: Duplicated ban detection [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 778
Loc: The Netherlands
Hm, but then the contents of $ibl may still end up being "wrong" (in the sense of the original post here) if mIRC retains its fully case-insensitive ban tracking based on MODE +b/-b changes?

Also, that means that after a ban list has been requested already, half the ban list may still be missing from the $ibl list during a new channel-central-incurred banlist update (ie during the $inmode state) from a script's point of view?

I think this does have the potential to break some scripts, especially those implementing their own channel central kind of thing..

I don't know, is telling UnrealIRCd to get their shit together not a better option after all? smirk
_________________________
Saturn, QuakeNet staff

Top
#260271 - 24/03/17 03:26 PM Re: Duplicated ban detection [Re: Sat]
Khaled Offline


Planetary brain

Registered: 04/12/02
Posts: 3841
Loc: London, UK
Quote:
Hm, but then the contents of $ibl may still end up being "wrong" (in the sense of the original post here) if mIRC retains its fully case-insensitive ban tracking based on MODE +b/-b changes?

mIRC would not be tracking or storing the contents of mode changes - all it would see is that eg. a new mode +/-b had arrived, so it would change the state of .ibl to $false.

Quote:
Also, that means that after a ban list has been requested already, half the ban list may still be missing from the $ibl list during a new channel-central-incurred banlist update (ie during the $inmode state) from a script's point of view?

This has always been the case though. That is why $inmode was added, so that scripts would know if it was being looked up.

Quote:
I think this does have the potential to break some scripts, especially those implementing their own channel central kind of thing.

I am concerned about that, however it seems okay so far... if a script is checking for the .ibl value, it will continue to work as before. If it isn't checking for the .ibl value, then it never had a guarantee that the list was filled anyway.

Quote:
I don't know, is telling UnrealIRCd to get their shit together not a better option after all?

It sure would be :-)

Top
#260272 - 24/03/17 03:49 PM Re: Duplicated ban detection [Re: Khaled]
Sat Offline
Hoopy frood

Registered: 19/04/04
Posts: 778
Loc: The Netherlands
Originally Posted By: Khaled
mIRC would not be tracking or storing the contents of mode changes - all it would see is that eg. a new mode +/-b had arrived, so it would change the state of .ibl to $false. [..] This has always been the case though. That is why $inmode was added, so that scripts would know if it was being looked up.

Oh I see. Yes, I do think that is very likely to break scripts then: as far as I know -correct me if I'm wrong- it is currently the case that after the the ban list has been requested once (after joining the channel), a script could assume that the IBL would accurately reflect the bans set on the channel. As such, a script could issue a "/mode # b" on join and, after the final numeric reply, assume that the IBL would be in good shape for as long as the client is on the channel. This change would break that assumption and as such even make $ibl nearly useless, I think..


Edited by Sat (24/03/17 03:51 PM)
Edit Reason: clarity
_________________________
Saturn, QuakeNet staff

Top
Page 1 of 2 1 2 >