mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#260243 20/03/17 08:28 PM
Joined: Mar 2017
Posts: 1
N
NoMiaus Offline OP
Mostly harmless
OP Offline
Mostly harmless
N
Joined: Mar 2017
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.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
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
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
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
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Feb 2003
Posts: 2,812
Hoopy frood
Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
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


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
That sounds reasonable but what about $ibl etc then though?


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
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
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
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 :-)

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
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..

Last edited by Sat; 24/03/17 03:51 PM. Reason: clarity

Saturn, QuakeNet staff
Page 1 of 2 1 2

Link Copied to Clipboard