View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002006 | unreal | ircd | public | 2004-08-04 21:58 | 2005-02-26 19:29 |
| Reporter | Assigned To | syzop | |||
| Priority | normal | Severity | text | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002006: I think is a small text error in /whois with ssl | ||||
| Description | /whois user user is [email protected] * user user is connecting from *@XXXXXXXXX.net 217.xxx.xxx.xxx user on +#ssl user using irc.xxxxxxxx.net user is a Secure Connection <=== ? he/she is not a connection he/she has one :) user has been idle 5secs, signed on Wed Aug 04 22:49:35 user End of /WHOIS list. "user has a Secure Connection" | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| related to | 0003401 | closed | numeric 671 description |
|
|
I'm just wondering here.. I doubt there are many clients/scripts really parsing this and taking certain action if it is 'is a Secure Connection'.. is there any proof otherwise? 320 has (at least) 3 numerics, according to http://www.alien.net.au/irc/irc2numerics.html: 320 RPL_WHOISVIRT AustHex 320 RPL_WHOIS_HIDDEN Anothernet 320 RPL_WHOISSPECIAL Unreal RPL_WHOISSPECIAL is used for both 'is a secure connection' as for custom SWHOIS titles. So I don't think we should run in any display problems? (since it could already be a different title due swhois) Only thing is if a client actually looked at the exact text 'is a Secure Connection' and took action upon that. I doubt there would be many problems. But again, feel free to prove otherwise ;). I'm just taking it a bit more seriously since it has been reported at least 2 times now (I think even more), and I've even seen people being bothered so much about it that they even modify the source for it ;). I know neither of these 'reasons' means per-se that things should be done 'because users requested it' (there are plenty of other examples of feature requests [eg: +I] that we will always refuse), but.. perhaps we could analyse the real consequences of this a bit more? |
|
|
*change to private to get rid of any noise* |
|
|
*make even more private / masskill irelevant stuff*.. sorry ;p note: original reporter was 'crazy', original reaction of Dukat was with references to 2 previous bugreports, blah. edited on: 2004-08-05 04:01 |
|
|
Honestly, I hate the fact that it uses WHOISSPECIAL. That was a horrible, horrible idea. |
|
|
Yeah I wondered about that too ;). |
|
|
Syzop, when you get a chance/are feeling better, I noticed this: 671 RPL_WHOISSECURE KineIRCd <nick> <type> [:<info>] Reply to WHOIS command - Returned if the target is connected securely, eg. type may be TLSv1, or SSLv2 etc. If the type is unknown, a '*' may be used. I don't quite like that "type" thing, that sounds like "exploit me!" i.e. you can assume 90% of SSL users are running OpenSSL, so if you know there is an SSLv2 exploit, you know they are exploitable. So imho, we should just send an * for that. But the numeric itself seems nice. "codemastr * :is using a Secure Connection" that way when we change it, we're not completely ruining compatibility with clients since we're using an existing numeric. |
|
|
Right, looks interresting indeed. Should take a look about a week or so. |
|
|
Hm, something I realized.. when we change numerics clients would have to be updated again due to functions like show-whois-in-active-windows (like I constantly use), the blalba is a secure connection would be shown in status while the rest is in my current window (like on mIRC) :p. Also, this KineIRCd seems not something very 'alive'. I looked at their sourceforge and they don't have any files and development is semi-dead. Unless of course, they have some other site somewhere, but I couldn't find it by google;). Hm :P [edit] in mIRC it would be shown like this btw: * is using a Secure Connection [/edit] edited on: 2004-10-11 19:52 |
|
|
Stupid mIRC... I'd really like to stop it from using SWHOIS. And I think the best way to do that The mIRC way of displaying it is clearly a bug. I don't know why it would parse it like that. As for show-in-active, the consensus seems to be that this is very easy to do. When you receive a 311, set in_whois. Until you receive a 318, you hide treat everything in between (that is from the local server) as part of a whois. So if mIRC doesn't do that, it's really yet another mIRC bug. |
|
|
Hm yeah, but that doesn't solve all the problems, like stuff like remote whois (which is pretty common due to users wanting to know idle time). Unless of course you even keep track of that.. ;). *grin* Anyway, if you think this is better.. we could still do it, it's just a tad annoying. Perhaps we could report this to the mIRC guys as soon as we add it. I also noticed another numeric: Ein is using modes +iowghaAsN +kcfvGqso going into status instead of current window. I just know, from the past, it took a long time till they added the numerics, so I hope they do it pretty fast now then. About the * displaying.. I dunnow.. guess it depends on how you look at it. Like with the previous example, I presume that numeric is just not handled at all in the code [:maintest.test.net 379 dhsasad Ein :is using modes +iowghaAsN +kcfvGqso] Still, due the way they display it (Ein is using modes...) it displays it pretty fine. Ah well ;). Actually when I think of it.. is it really logical to put '*' @ 2nd parameter? Usually such numerics are like.. :name.of.server NUMERIC me target-of-whois :sometext Or is that not really a rule? :p I mean, then it's suddenly: :name.of.server NUMERIC target-of-whois * :sometext [ex: <- :maintest.test.net 311 dhsasad Ein none syzop.hoklan * :fdsdsffds <- :maintest.test.net 379 dhsasad Ein :is using modes +iowghaAsN +kcfvGqso <- :maintest.test.net 378 dhsasad Ein :is connecting from *@syzop.hoklan 192.168.5.24 <- :maintest.test.net 312 dhsasad Ein maintest.test.net :Syzop - TestNet server <- :maintest.test.net 313 dhsasad Ein :is a Network Administrator <- :maintest.test.net 310 dhsasad Ein :is available for help. <- :maintest.test.net 317 dhsasad Ein 2591 1097522707 :seconds idle, signon time <- :maintest.test.net 318 dhsasad ein :End of /WHOIS list. ] |
|
|
[quote]Usually such numerics are like.. :name.of.server NUMERIC me target-of-whois :sometext Or is that not really a rule? :p I mean, then it's suddenly: :name.of.server NUMERIC target-of-whois * :sometext[/quote] No? It is: :name.of.server NUMERIC me target-of-whois * :sometext It has an additional parameter, not a replaced one. There can be more than just a text parameter. Look at 311. <nick> <user> <host> * :<real_name> It's not :<nick> <user> <host> * :<real_name>, it has multiple parameters. And that is what this SSL numeric does. |
|
|
(Yeah I know they can have multiple params, just didn't realize they didn't document the 1st param {nick-of-yourself}) Anyway, hmm.... mIRC: Ein is [email protected] * fdsdsffds Ein is connecting from *@syzop.hoklan 192.168.5.24 Ein using maintest.test.net Syzop - TestNet server Ein * is using a Secure Connection Ein has been idle 5secs, signed on Tue Oct 12 00:41:12 Ein End of /WHOIS list. irssi: 00:42 -!- syzop [syzop@localhost] 00:42 -!- ircname : Syzop 00:42 -!- : is connecting from *@localhost 127.0.0.1 00:42 -!- server : maintest.test.net [Syzop - TestNet server] 00:42 -!- : * 00:42 -!- idle : 0 days 0 hours 0 mins 19 secs [signon: Tue Oct 12 00:41:39 2004] 00:42 -!- End of WHOIS Hm. Since we aren't using that 3rd parameter (*) anyway, why not just drop it? Sure, then you got 2 variations in the numeric, but I'm not sure if that's so bad (basically just let clients grab the last param) ;). It would at least fix the display problems :p. I mean, it's kinda annoying to use a numeric that only exists on paper that causes this annoying stuff. On a sidenote, I noticed that quite some ircds are using another numeric, RPL_USINGSSL [275], not documented in the irc/2 list (in fact, it collides with RPL_STATSDLINE). :%s 275 %s %s :is using a secure connection (SSL) The following ircds use RPL_USINGSSL: - bahamut-inet6 (an ipv6/ssl patch for bahamut) - rageircd (they even used RPL_WHOISSECURE at first, but changed to 275) - tr-ircd But since we are even using RPL_STATSDLINE ourselves, using it obviously would be a bad bad idea ;). |
|
|
what is statsd used for? Debug? |
|
|
deny link stuff [stats_denylinkall, stats_denylinkauto] :/. Or do you think we should use it? ;) |
|
|
ok, I'm just gonna take RPL_WHOISSECURE and change it a bit, get rid of the "*" param. I really don't see any use for the param, but more important (I know! I'm just lame that I don't persist as an ircd coder) clients display it properly then (although in-window-/whois gets broken of course). I figured, that would be better than introducing a THIRD ssl numeric :p. |
|
|
Done in .294. Would it be useful to notify mIRC coders or things like that about this? (in-window-/whois gets broken, but other whoiss [entirely in status] work fine). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-08-04 21:58 | crazy | New Issue | |
| 2004-08-04 22:26 | syzop | Note Added: 0007309 | |
| 2004-08-04 22:26 | syzop | Note Added: 0007310 | |
| 2004-08-04 22:26 | syzop | View Status | public => private |
| 2004-08-05 03:59 | syzop | Note Added: 0007313 | |
| 2004-08-05 04:00 | syzop | Reporter | crazy => user4417 |
| 2004-08-05 04:00 | syzop | Status | new => feedback |
| 2004-08-05 04:01 | syzop | Note Edited: 0007313 | |
| 2004-08-05 04:01 |
|
Note Added: 0007314 | |
| 2004-08-05 04:04 | syzop | Note Added: 0007315 | |
| 2004-09-04 04:37 |
|
Note Added: 0007505 | |
| 2004-09-09 00:42 | syzop | Note Added: 0007597 | |
| 2004-10-11 19:45 | syzop | Note Added: 0007970 | |
| 2004-10-11 19:52 | syzop | Note Edited: 0007970 | |
| 2004-10-11 20:00 |
|
Note Added: 0007971 | |
| 2004-10-11 20:14 | syzop | Note Added: 0007972 | |
| 2004-10-11 21:12 |
|
Note Added: 0007973 | |
| 2004-10-11 23:10 | syzop | Note Added: 0007974 | |
| 2004-10-11 23:33 |
|
Note Added: 0007975 | |
| 2004-10-11 23:35 | syzop | Note Added: 0007976 | |
| 2005-02-26 19:14 | syzop | Note Added: 0009329 | |
| 2005-02-26 19:14 | syzop | Status | feedback => assigned |
| 2005-02-26 19:14 | syzop | Note Edited: 0009329 | |
| 2005-02-26 19:28 | syzop | Reporter | user4417 => |
| 2005-02-26 19:28 | syzop | View Status | private => public |
| 2005-02-26 19:29 | syzop | Status | assigned => resolved |
| 2005-02-26 19:29 | syzop | Fixed in Version | => 3.2.3 |
| 2005-02-26 19:29 | syzop | Resolution | open => fixed |
| 2005-02-26 19:29 | syzop | Assigned To | => syzop |
| 2005-02-26 19:29 | syzop | Note Added: 0009330 | |
| 2007-06-23 08:58 |
|
Relationship added | related to 0003401 |
