View Issue Details

IDProjectCategoryView StatusLast Update
0002888unrealircdpublic2007-01-22 06:43
ReporterdjGrrr Assigned Tosyzop  
Status resolvedResolutionfixed 
OS*OS Version* 
Product Version3.2.5 
Fixed in Version3.2.7 
Summary0002888: Virtual Ident
DescriptionCurrently, if you use /chgident or have services with HostServ that can change idents, it will change the ident field and will not keep track of the original ident, ie, in a /whois it will just say *@ for the ident for the actual host, i'd like to so an extra field for real ident, so doing a /whois will tell the real ident@hostname, this would allow giving out virtual idents as well as virtual hostnames, but still allow keeping track of real idents for banning purposes
TagsNo tags attached.
3rd party modules


child of 0003111 closed 3.2.7 Release 



2006-04-19 11:46

reporter   ~0011582



2006-04-19 15:15

reporter   ~0011583

although that is partially the same thing, that issue is closed.

I do not see a need for wasting the extra mem for real gecos; it was said that it can be used to keep out certain floodnets, which is true, BUT, in the event of a floodnet/botnet like that, you can usually tell with services the gecos, so theres no real issue.

The problem is idents, it would only be an addtional 11 or 12 bytes to keep track of the real ident, and it would prove to be very usefull in being able to use services that support ident@host vhosts, but still have the ability to know the real ident to use in glines/klines


2006-04-19 15:52

reporter   ~0011585

Except idents can also be changed (not quite as easily as realnames but these days...).


2006-12-11 08:30

reporter   ~0012814

maybe this could be something for 3.3?
i'd certainly like to see it as it would greatly help for security in cases where someone is using a shell where the ident can't be changed, and they are using a vhost with an ident


2006-12-12 09:57

administrator   ~0012815

I wonder if, when I add this, people would ask for the ident@ being checked in channel bans as well... Because I would be surprised if people won't bother me with that request :P.
We then have to check channel bans against like 8 possibilities, instead of 4... it's getting worse and worse :P
Anyway, just to say: I won't do that.. ever.. :P

As for your point, the good news is that ident info is already stored in sptr->username. While the 'usual visible ident' (and subsequent /SETIDENT and /CHGIDENT's) are stored in sptr->user->username.
I suppose it wouldn't be too hard to change the 'is connecting from' line to user sptr->username instead of always saying *@ [and morph 'unknown' to '*' or something] ;)
Not for 3.2.6, but could be done in 3.2.7 easily.


2006-12-12 10:26

reporter   ~0012817


and i see what you mean about all the ban checking, and i just had an interesting thought.

If the main bans +b was set only to check the current vident@vhost + realident@realhost (which would really only need 2 checks), that would mean less checks, making things faster, then, you could add an extended bantype, which would only check against the cloaked hosts, this should allow for much faster ban checking, while still giving just as good functionability with the bans.

what do u think about this idea ? good? bad? i'll open up another report if you think its a good idea :)


2006-12-12 10:38

administrator   ~0012818

I'm not going to add a new check to standard ban checking (such as realident@realhost) :P.

2006-12-28 11:45


realidentwhois.patch (1,542 bytes)


2006-12-28 11:45

reporter   ~0012940

i decided to make a patch for this and attached it :)


2006-12-28 11:49

administrator   ~0012941

Looks good :)
(or at least until I noticed next..)

Only thing I just realized is... only the server the user is on knows this info, remote servers don't (AFAIK). Fun.


2006-12-28 11:55

reporter   ~0012942

Last edited: 2006-12-28 12:05

hmmm, yeah, that is a problem, hmmm, i guess i could add another check:
(acptr-username && strcmp(acptr-username, "unknown"))
this should work right?, then it should only be shown on remote queries, and not crash on local queries of a remote user :P

there is an issue with this though
if the real ident is "unknown" it is displayed as *, maybe the default username when no ident is specified should be something that is not a valid ident (just use * maybe) ? this would make it all even simpler

what do you think syzop ?

2006-12-28 12:51



2006-12-28 12:54

reporter   ~0012948

Last edited: 2006-12-28 16:19

i've added another patch that fixes the remote query problem, and also the issue when the real ident is literally unknown (i changed "no ident" from unknown to *); from my grep through the code, I did not see anything there that should be affected by this change


2006-12-30 08:52

reporter   ~0012956

I did a little more testing and it seems nothing is broken with this change, link blocks and oper blocks still all match properly.

2007-01-01 01:43



2007-01-01 01:48

reporter   ~0012962

i added another patch that is a slight change, now its using ~ as the no ident identifier.

i made this change because in a case where something is matching the real ident (allow/tld blocks maybe? I'm not sure), you can still easily match clients that have no ident (since * is used as a wildcard its impossible to match it)

and since ~ is the regular no ident identifier, matches like ~*@* work properly :)


2007-01-09 07:55

administrator   ~0013039

I'm not too eager to change to change the unknown thing, as in.. the possible unknown effect on other things. I'll use a simple (older?) patch instead for 3.2*.

But at least some version will get in then :)

2007-01-14 10:55


2007-01-14 10:59



2007-01-14 11:00

reporter   ~0013054

I've added 2 new patches, once for 3.2, and another for 3.3 (assuming devel is the right CVS branch)


2007-01-22 06:43

administrator   ~0013082

Thanks, committed both to CVS (32&33) :)

- /WHOIS now shows the ident of local users - if ident enabled and they had an ident -
  instead of always "*" in the 'is connecting from' line. Suggested and patch provided
  by djGrrr (0002888).

(and the 33* changelog with a "plz to check this"-style warning)

Issue History

Date Modified Username Field Change
2006-04-19 11:23 djGrrr New Issue
2006-04-19 11:46 aquanight Note Added: 0011582
2006-04-19 15:15 djGrrr Note Added: 0011583
2006-04-19 15:52 aquanight Note Added: 0011585
2006-12-11 08:30 djGrrr Note Added: 0012814
2006-12-12 09:57 syzop Note Added: 0012815
2006-12-12 09:58 syzop Relationship added child of 0003111
2006-12-12 10:26 djGrrr Note Added: 0012817
2006-12-12 10:38 syzop Note Added: 0012818
2006-12-28 11:45 djGrrr File Added: realidentwhois.patch
2006-12-28 11:45 djGrrr Note Added: 0012940
2006-12-28 11:49 syzop Note Added: 0012941
2006-12-28 11:55 djGrrr Note Added: 0012942
2006-12-28 11:56 djGrrr Note Edited: 0012942
2006-12-28 11:56 djGrrr Note Edited: 0012942
2006-12-28 11:56 djGrrr Note Edited: 0012942
2006-12-28 12:05 djGrrr Note Edited: 0012942
2006-12-28 12:51 djGrrr File Added: realidentwhois+unkownidentfix.patch
2006-12-28 12:54 djGrrr Note Added: 0012948
2006-12-28 13:09 djGrrr Note Edited: 0012948
2006-12-28 16:19 djGrrr Note Edited: 0012948
2006-12-30 08:52 djGrrr Note Added: 0012956
2007-01-01 01:43 djGrrr File Added:
2007-01-01 01:48 djGrrr Note Added: 0012962
2007-01-09 07:55 syzop Note Added: 0013039
2007-01-09 07:55 syzop Status new => acknowledged
2007-01-14 10:55 djGrrr File Added: realidentwhois.unreal32.patch
2007-01-14 10:59 djGrrr File Added: real_and_unknown-identwhois.unreal33.patch
2007-01-14 11:00 djGrrr Note Added: 0013054
2007-01-22 06:43 syzop Status acknowledged => resolved
2007-01-22 06:43 syzop Fixed in Version => 3.2.7
2007-01-22 06:43 syzop Resolution open => fixed
2007-01-22 06:43 syzop Assigned To => syzop
2007-01-22 06:43 syzop Note Added: 0013082