Re: Re: RFC: ircd choice vote

Philipp Kern wrote:

> On Aug 6, 2005, at 1:29 AM, Mark Rutherford wrote:
>
>> The issue with that is the keys need to be provided to the server  admin
>> and all servers need the same keys.
>
>
> Why is this an issue? We need to trust our server admins anyway. But 
> you could implement the possibility to inject them on-the-fly via U-
> lined servers. But then the keys in the config file wouldn't be updated.
>
The issue is they all need to be updated at the same time.
Each server has to have the capability of coming up with the same result.
If they do not then one server says your abc.hostname and another says
yout xyz.hostname

>From our experience, we have never had to change the keys. we set them
and leave it at that
Granted, it is possible to brute force it.... and if you have the time
and desire I say go for it.
Its not 'super secure' but it makes it really hard for someone to get
your ip.

Unless you reveal your address, most people wont try to crack it.
(dcc would reveal your address)

NOW, it could be changed to have a default key that it would use in the
event that services doesnt provide a key.
Im sure services can easily be altered to send a key to a connecting
server, and if that server does not get a key
from services to use the key from the config file.
This is really all just brainstorming, it has not been implemented in
any fashion.
I have my reservations about handing off a lot of responsibility to
services expecially when all it takes
is losing services to cause problems with stuff like this.

One ongoing internal project I have is a second server, call it stats,
services2, what have you.
The goal of this other server is statistical information (like Thales)
and the enforcement of akills/clone detection, ect
It would only activate when main services died. But, while services is
running it would be in a sort of 'learning mode'
learning the akills that exist from main services and enforcing them
when it went down.
It really sounds like overkill, but it was one of those things I had to
play with.
Its actually running in some capacity now, but only collecting
statistics. Its a slow moving 'toy'
(Since I dont know if it will actually have any good use)
The fear was (on FreeQuest) that since we tell the userbase about
scheduled maintenance
like, if we move services or we take the machine down for any reason
that some crafty users will do something
obnoxious like load clones and flood channels. the ircd level join flood
protection takes care of some of that
but they still try. It just reinforces the fact that something like this
is useful.

OK ... Enough rants :)

> Kind regards,
> Philipp Kern
>