Re: Anti-collide patch

[Matthew Sullivan <mickey@xxxxxxxxxxxxxxx>]

Michal *pht* Svoboda wrote:
> 
> On Sun, 10 Jan 1999, Joern Westermann wrote:
> 
> > Kaspar Landsberg wrote:
> > >
> > > the problem with the FNC (forced nick change) solution is that it can easily
> > > result in a loop. Suppose a nick collision happens and Guenthi changes to
> > > Guent6387. But now, there´s some guy sitting on one of your channels and
> > > sees that you get a new nick. All he needs now is a lagged server or a
> > > server which is currently reconnecting and he can hook up "on the other
> > > side" a client with the same nick, resulting in a nick collision, which
> > > makes the whole thing restart from 0 ad infinitum.
> >
> > I know. This way a channel cannot be taken over, but it'll be a totally
> > useless channel. But I could also think about a script to defend against
> > this approach: It notices a collide and after the channel rejoin it
> > kicks out all non-channel ops and sets the channel +i. So it's
> > impossible for the attacker to find out the new nick after the next
> > collide.
> > Ok, I also hate those warscripts. :(
> this wouldnt be any use because the attacker sits on lagged server, which
> doesnt get the kick.

Ah but it would, cause the lagged server won't get the new nick until
the kick has already got there....

However I see your point, multiple clients would solve it if they all
notice the collide and clear the chan, rather than changing nicks (as in
the usual lame anticollide scripts) it will sort it...  If the oper is
the last op in channel it'll have a problem.  

The other think is to send a new code out to the server _BEFORE_ the
change takes place locally, which locks the new nick before the change
happens (and kills anything with it/forces it's nick to change..), the
only problem in this approach is that you'll probably get one or two
innocent lusers.  But that could of course happen with a FNC in the
first place anyhow....

...and we go round, and round, and round, and round....

Yours

Mickey