View Issue Details

IDProjectCategoryView StatusLast Update
0002006unrealircdpublic2005-02-26 19:29
Reporter Assigned Tosyzop  
PrioritynormalSeveritytextReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version3.2.3 
Summary0002006: 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"
TagsNo tags attached.
3rd party modules

Relationships

related to 0003401 closed numeric 671 description 

Activities

syzop

2004-08-04 22:26

administrator   ~0007309

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?

syzop

2004-08-04 22:26

administrator   ~0007310

*change to private to get rid of any noise*

syzop

2004-08-05 03:59

administrator   ~0007313

Last edited: 2004-08-05 04:01

*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

codemastr

2004-08-05 04:01

reporter   ~0007314

Honestly, I hate the fact that it uses WHOISSPECIAL. That was a horrible, horrible idea.

syzop

2004-08-05 04:04

administrator   ~0007315

Yeah I wondered about that too ;).

codemastr

2004-09-04 04:37

reporter   ~0007505

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.

syzop

2004-09-09 00:42

administrator   ~0007597

Right, looks interresting indeed. Should take a look about a week or so.

syzop

2004-10-11 19:45

administrator   ~0007970

Last edited: 2004-10-11 19:52

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

codemastr

2004-10-11 20:00

reporter   ~0007971

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.

syzop

2004-10-11 20:14

administrator   ~0007972

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.
]

codemastr

2004-10-11 21:12

reporter   ~0007973

[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.

syzop

2004-10-11 23:10

administrator   ~0007974

(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 ;).

codemastr

2004-10-11 23:33

reporter   ~0007975

what is statsd used for? Debug?

syzop

2004-10-11 23:35

administrator   ~0007976

deny link stuff [stats_denylinkall, stats_denylinkauto] :/.
Or do you think we should use it? ;)

syzop

2005-02-26 19:14

administrator   ~0009329

Last edited: 2005-02-26 19:14

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.

syzop

2005-02-26 19:29

administrator   ~0009330

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).

Issue History

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 codemastr Note Added: 0007314
2004-08-05 04:04 syzop Note Added: 0007315
2004-09-04 04:37 codemastr 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 codemastr Note Added: 0007971
2004-10-11 20:14 syzop Note Added: 0007972
2004-10-11 21:12 codemastr Note Added: 0007973
2004-10-11 23:10 syzop Note Added: 0007974
2004-10-11 23:33 codemastr 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 stskeeps Relationship added related to 0003401