View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002343 | unreal | ircd | public | 2005-02-14 15:25 | 2005-03-01 16:20 |
| Reporter | auspice | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 3.2.2 | ||||
| Summary | 0002343: Java user and channel | ||||
| Description | add umode +j and cmode +J Where umode +j only add by the server, some network maybe able to write their own IRC Client and IRCd module to give their IRC Client user umode +j (safe or trusted client). umode +j able to join +RJ without identify nickname since we have cmode +j make +j client known as the safe client able to by passed the throttle. Just ideas only | ||||
| 3rd party modules | |||||
|
|
What stops anyone from setting himself +j (and perhaps spoof/emulate some other stuff if needed) and then bypassing all these protections? [A: Nothing.. Since anything you run at a computer the "bad guy" owns is in his control so any method you might use is flawed by design :P.] {just in case anyone starts about CGI:IRC... CGI:IRC is a different case, since you can specify 1 or a few hosts that can be trusted (the ones with the cgi script).} |
|
|
Personally, +R is set for a reason - you only want registered nicks to join. Why should java users be immune to it? Make 'em register like everyone else. Also, this is why unreal supports modules. :) Even if you find a suitable way to do this, I think this is more appropriate to be coded as an extra module. |
|
|
passing all the protection is not true, because channel operator can do cmode -J any time. my concept is to have a safe client and server know that it safe, so each network can design their own client for it (whatever or however they do it) |
|
|
And what stops a bad guy from pretending to be this "safe" client? Unless you're planning to use some kind of SSL signed java client that the server will verify the certificate of (which, fyi, Unreal has no way of doing) there is no way of ensuring that the user is really running the "safe" client. Hence, anyone can fake it. It's just like when people hide a "PASS mypass" inside a javachat in hopes of preventing mIRC user from connecting. All I do is run a sniffer on my machine and see that the javachat sends "PASS something\r\n" and now I know how to connect. Whatever method the javachat uses to authorize itself can be spoofed. The only methods that can not be spoofed would require significant modifications to Unreal. Seeing as how we do not support Unreal modifications, I see no reason to add a mode to Unreal that is only functional when people modify it! |
|
|
If you want "safe clients" you have two things that can help you: 1) CGI:IRC 2) INVEX Since CGI:IRC connects with the hostname of the webserver hosting it, just +iI *!*@cgiirc.ip.address, provided you don't use whatever extension to turn the cgiirc hostname into the cgier's real host. |
|
|
I believe this idea came from ConfrerenceRoom, as they have the same concept... The way CR does this, is the java applet is hosted by the server itself, so the server knows who is a real java client, and who isnt. I, like most, think such a thing is not a very good idea. Implementing this modeset would require Unreal to have a java client integrated into it. IMHO, Unreal should never go the way of CR and be java-based in such a way. I think that is what made CR so crappy, aside from lousy linkage/uptime/services. If a java client is implemented into Unreal, what next... 30000 requests for services to be implimented like CR too?! Get real, this is IRC, not javaland. |
|
|
as mentioned there is absolutely no safe way to implement this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-02-14 15:25 | auspice | New Issue | |
| 2005-02-14 15:30 | syzop | Note Added: 0009133 | |
| 2005-02-14 15:30 | syzop | Note Edited: 0009133 | |
| 2005-02-14 15:47 | aquanight | Note Added: 0009134 | |
| 2005-02-14 16:07 | auspice | Note Added: 0009136 | |
| 2005-02-14 18:18 |
|
Note Added: 0009137 | |
| 2005-02-14 18:22 | aquanight | Note Added: 0009138 | |
| 2005-02-20 15:39 | Stealth | Note Added: 0009199 | |
| 2005-03-01 16:20 | syzop | Status | new => closed |
| 2005-03-01 16:20 | syzop | Note Added: 0009384 |
