RE: [NeoStats-Devel] Secureserv and non-VERSION ctcp requests

> -----Original Message-----
> From: M [mailto:[email protected]] 
> Sent: Thursday, August 18, 2005 7:29 AM
> To: [email protected]
> Subject: RE: [NeoStats-Devel] Secureserv and non-VERSION ctcp requests
> 
> 
> DeadNotBuried wrote:
> > With the number of posts on the forums about banning XDCC 
> > Ccatcher, bottlers and iroffer, and the number of networks 
> > running SecureServ that allow the same, i had the following 
> > thought to hopefully satisfy both camps.
> > 
> > if we add a CTCP request list which is empty by default, and 
> > as items are added (eg. LAG for XDCC catcher) SecureServ 
> > would send that request to each client connecting, and if it 
> > received a reply for that request it would automatically 
> > akill the client. or as an option for each request a warning 
> > could be sent, or a kill instead of an akill.
> > 
> > having it as a list would allow any extra replies that might 
> > crop up in the future to be added as well. setting it as 
> > default to be disbaled would keep things as they currently 
> > are, and those networks that want the extra function could use it.
> > 
> > thoughts ?
> 
> Why they feel the need to fake their version reply and 
> require networks to
> use custom extensions to the CTCP protocol to determine the 
> existence of a
> small subset of their clients (with the obvious potential for false
> positives in such detection) is IMO a statement on the morals of the
> creators rather than an appropriate way forward. As such I do 
> not see why we
> should mutate SecureServ to account for them.
> 

Agreed that its not cool how they do it, but I think DNB raised a
interesting idea, in that it would be good if we could extend the CTCP API
to process "unknown" CTCP message types in the future without having to go
and release new versions.

> It would be trivial to create a simple module that could 
> process such CTCP
> request/reply scenarios that users wanting such functionality 
> could use.
> E.g. AntiCTCPLag which simply sends the required CTCP 
> sequence and processes
> the reply accordingly.
> 
> Depending on ongoing discussions (rev 2699 thread), the CTCP 
> interface as
> designed could be simply and quickly adapted to accommodate 
> support for
> unsupported extensions such as this without affecting the 
> majority of the
> codebase. 
> 
> Now that Justin has some perl support available, I assume the 
> long planned
> perl support for SecureServ will follow which would again 
> offer some for of
> specific and optional support.
> 

Yes, and No. The perl support for SecureServ is more planned around logic
checks rather than additional checks. (eg, if Username and Nickname are the
same pattern etc, which is difficult, if not extremly inflexible, with the
current Dat file and use of plain regexs)


> Keeps SecureServ "clean" and optimal rather than trying to 
> create some form
> of adhoc support while providing a system for users that want to jump
> through the hoops of the creators of P2P over IRC apps.
> 
> Remember the most important issue here is that very few of 
> the clients will
> actually be caught by the CTCP LAG sequence and you run the 
> risk of false
> positives by relying on such claims. It is their attempt to 
> suggest they are
> being helpful but their refusal to just provide a fixed CTCP 
> VERSION field
> suggests otherwise. Same goes for anything else they publish 
> for a subset of
> their clients including the "add this exact string to MOTD" 
> rubbush which
> again will only reject a small subset. If you follow all 
> their rules, you
> end up with a MOTD which is little more than anti client 
> commands which
> looks like it was written by a 4 year old Russian learning 
> English using
> only Japanses translations written in Greek and sending 
> various strange CTCP
> messages to every user but still do not actually detect the majority.
> 

I also think though it would be "ideal" to have the core be able to process
any CTCP message, rather than the strict types we have now. Say a "catchall"
CTCP reply handler, that is triggered if the reply doesn't match a known
type (TIME, VERSION etc). We would then need to have a generic CTCP send
interface as well to specify the type of message to send.

This way, should a new trojan/bot come out (there are already a few out
there now) that warrant a new type of CTCP check, we can easily implement it
via the Dat file (with some modifications of course to the Dat file, which
will have to happen with the planned perl support regardless)




> Many spam messages have offered a "remove" link even before 
> the pathetic
> legal requirements to do so. Research has shown it is BS. Until proven
> otherwise, I will continue to believe that the steps offered 
> by these client
> creators are nothing more than a "spam me more" removal link 
> in that they
> are as effective as a chocolate fire guard.
> 
> I do not mean to rain on your parade since I know you are 
> trying to find a
> solution. I do think the solution is in the module CTCP interface and
> encouraging someone to write a simple module rather than us 
> making such a
> change to SecureServ. I will not write the module and I am 
> guessing Justin
> is equally unlikely to do so for either similar personal 
> concerns or time
> constraints. 

Well, like you state below, just a generic catchall CTCP interface should be
what we look for, then we can easily extend SecureServ with a new dat file
rather than a new release. 


If you wish to, that is fine and I will provide 
> whatever core
> support is required for non-standard CTCP protocol messages 
> you might need
> since it is something I need to do anyway for both CTCP and the DCC
> extensions. If not, the only thing I could say is that our response to
> requests becomes write a module that calls the (to be written)
> irc_ctcp_unknown_req and processes EVENT_CTCPUNKNOWNRPL or 
> similar interface
> to IRC.
> 
> Mark.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> For additional commands, e-mail: [email protected]
> 
>