[IRCServices] Kick war with ChanServ, for the 135175631861th time..
Anton Wolkov
phan70m at gmail.com
Sun Jan 6 05:08:23 PST 2008
there are many issues with unreal, since i had a chance to build my own
unreal services i stumbled a lot of sync issues.
here are some issues, some of which (but not all) are already handled:
+b can be overridden or be desynced.
here are the reasons i remember for overrides:
user who gets an /invite (services invite too in ajoin etc)
user who has +e *!*@*
+e can include shit loads of extensions i.e. +e ~c:#opers or ~r:gekos
+I acts like /invite and also may include weird extensions
and when u handle all that you need to start taking into account services
timestamp desync handler,
generally speaking, if your timestamp is higher than the one the ircd sends
you, you need to discard your modes, if they are identical, you need to do
an awkward merge, and if you have a lower value discard everything the
server just told you.
btw, are time desyncs (TS) taking into account here? usually not an issue
when services link to localhost, but i've seen different setups.
sounds simple? sure, just a couple more ideas
my implementation unsets a ban after 5 minutes, to avoid ban list getting
filled, and akicks/restricts always set a ban in *!*@host form to avoid
dbls.
some modules allow opers to override but that's obvious.
i've still didn't have a chance to figure out the new maskign module (thanks
ircd for sending * instead of the actual value) so i do USERHOST nick1 nick2
nick3 on every connect to get in sync.
i've implemented ALL of that, and guess what, on extremely rare occasions, i
still get a desync issue (my services think ban is set but it's not).
i'm pretty sure it's just a protocol compatibility issue and not the
services fault (although implementing more of the protocol would help), so
my solution is to set +f with user join flood protection that bans users and
unsets the bans after 5 minutes.
On Jan 6, 2008 2:05 AM, Robin Burchell <robin at en2no.com> wrote:
> No +I masks, three +e masks are set, neither of which match me..
>
> #helpers *!*@herring.chatspike.net set by Om (Sat Nov 03 23:13:31)
> #helpers *!*@helper.chatspike.net set by Om (Sat Nov 03 23:13:27)
> #helpers *!*@tortoisegod.chatspike.net set by Om (Sat Nov 03 23:13:21)
> #helpers End of Channel Exception List
> -
> #helpers End of Channel Invite Exception List
>
> w00t is w00t at globop.chatspike.net * Master of all trades; jack of none
> <- being me.
>
> Explicit invite - (as in /invite?) - aren't used on that channel. It's
> also perhaps worthy of note that /invite only overrides ban on some
> software.
>
> I imagine the problem was caused as some IRCds will propegate the ban
> anyway (no duplicates checking) from a server to server link, so I
> guess that could be construed as a problem of sorts, though not a
> major one.
>
> Given the infrequency of this problem, I don't mind waiting until the
> list archives are back up for you to check, by all means. :)
>
> On Jan 5, 2008 11:52 PM, Andrew Church <achurch at achurch.org> wrote:
> > >I understand it must be frustrating to have an issue like this that's
> > >so hard to track down, but it is equally frustrating to get bit in the
> > >ass by it. Isn't it wise to assume that if they are joining an
> > >existing channel that a ban matching them doesn't exist anyway
> > >(otherwise how are they joining?)
> >
> > +e, +I, explicit INVITE, possibly other methods. Originally, I didn't
> > bother checking for the ban, but apparently it caused a problem, because
> > I added the check in 4.5pre0:
> >
> > 2001/01/11 Fixed duplicate adding of bans when auto-kicking a user
> > from a channel. Reported by James <
> daemus at evilcode.com>
> > --- chanserv.c 11 Jan 2001 00:03:56 -0000 1.10
> > +++ chanserv.c 11 Jan 2001 04:29:13 -0000 1.11
> > @@ -670,10 +670,13 @@
> > #else
> > }
> > #endif
> > - av[1] = "+b";
> > - av[2] = mask;
> > - send_cmd(s_ChanServ, "MODE %s +b %s %lu", chan, mask, time(NULL));
> > - do_cmode(s_ChanServ, 3, av);
> > + /* Apparently invites can get around bans, so check for ban first
> */
> > + if (!chan_has_ban(mask)) {
> > + av[1] = "+b";
> > + av[2] = mask;
> > + send_cmd(s_ChanServ, "MODE %s +b %s %lu", chan, mask,
> time(NULL));
> > + do_cmode(s_ChanServ, 3, av);
> > + }
> > free(mask);
> > send_cmd(s_ChanServ, "KICK %s %s :%s", chan, user->nick, reason);
> > if (stay) {
> >
> > The list archives are down at the moment, so I can't check exactly what
> > the problem was, whether it was a serious issue or just cosmetic; I'm
> > hesitant to remove the check without knowing more. (Of course, you're
> > welcome to try removing it yourself and seeing what happens.)
> >
> >
> > --Andrew Church
> > achurch at achurch.org
> > http://achurch.org/
> >
> > ------------------------------------------------------------------
> > To unsubscribe or change your subscription options, visit:
> > http://lists.ircservices.za.net/mailman/listinfo/ircservices
> >
>
>
>
> --
> Robin Burchell
> mob: +447702671419
> msn: msn at viroteck.net
> web: http://www.en2no.com
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://lists.ircservices.za.net/mailman/listinfo/ircservices
>
--
Best Regards,
Anton Wolkov
Information Security Expert | BugSec Ltd.
Mobile: 054-7703580 | Office: 03-9622655
Visit us at our web site: www.bugsec.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: ../attachments/20080106/61013a93/attachment.html