Quassel IRC

Ident servers are expected to listen on Port 113 which is a privileged port.
Though this sounds like a nice feature - and obviously one that could easily use the cores backend - I don't think that this is a good Idea.

Perhaps include it as an advanced and optional feature when there are some free resources...

That's a very valid point, and one I did not think of. One would probably need to have Quassel run as root, which is not a good idea for an IRC client, I guess. I don't know (but doubt) if there are ways to spawn a process with root privileges from an unprivileged process, or if one could allow an unprivileged process to open a certain privileged port.

Of course, most Linux users wouldn't mind to start a separate daemon, and I wouldn't be surprised if Windows allowed any process to open privileged ports, so having an included identd for such cases might still be a nice feature.

Probably not going to happen. identd is overrated anyway.

Some networks (such as Quakenet) require for special features (such as Trust) an identd server that allows to identify actual users/clients. AFAIK, for Quassel this cannot be done with a separate identd server running, since that couldn't know which connection belongs to which Quassel User.

For this reason, implementing identd support that reports a core user correctly should be taken on the agenda again. There still is the question how to handle the fact that 113 is priviledged - maybe provide a sort of relay for an external service? How do other daemons do that - most don't run as root even if they use a priv'd port?

They switch their uid/gid after setting up the privileged tcpsocket.
unistd.h provides setuid/setgid for any posix compatible OS.

What about using oidentd? oidentd is a seperate service which runs as Identd and handles $HOME/.oidentd.conf files. All you have to do is something like `echo $ID > $HOME/.oidentd.conf` and notify the daemon that you are about to claim the identd service for now (i really dont know the internals). Eggdrop uses it, psyBNC, sBNC, too.
It's packaged and available on all major distros.

This is a very hackish solution, and one that is bound to fail if multiple users connect to IRC at roughly the same time (which is quite common upon a quasselcore restart, for example).

The way oidentd works: Upon connect, the BNC writes the ID in the config file. If the identd request arrives after a short while, oidentd will use that ID. Now imagine what happens if 10 quassel users connect at the same time... all identd requests will get the same ID of the quassel user who initiated the connect last. This can be a major problem in particular in those scenarios where one actually needs identd, for example for a Quakenet trust.

In order to properly support Quassel, an identd daemon needs a way to map a port number to the actual user. If we don't want to do this from within quassel itself, we could have an external (custom) daemon that reads a config file / queries the db / uses dbus to access that information.

In either way you have to delay the reconnects. If all the users connect to one Network you have to do that anyway. A normal IRCd throttles connections from the same host. I don't think its very hackish because there are no other (efficient) ways to do that. You have to wait for each single user to receive an identd reply. Again, all the bouncer daemons i know of delay their reconnects upon startup (yes, I like bouncers, heh).

I'd rather not mix those two issues; throttling should be done automatically by the ircd (otherwise, I'd implement a connect delay into Quassel), but I don't want to depend on the ircd to actually ask for an identd reply. Also I wouldn't know how to figure out from within quassel if the request went through such that I could continue connecting.

Seriously, depending on the behavior of a race condition to perform a basic task like connecting to IRC does not sound like something I would want to support.

I'd much rather implement my own identd implementation tied to quassel via some sync mechanism (i.e. conf file or dbus) or even built into quassel than depend on something like that. After all, the protocol is damn simple. Queries not related to the running quasselcore could be relayed to a proper identd then that listens locally on a different port, this would avoid having to implement the full functionality of identd for the given host.

Another way would be to extend an existing identd (such as oidentd) to query the quasselcore for the correct information, but I think that's even more work and requires upstream cooperation.

Sputnick wrote:

The way oidentd works: Upon connect, the BNC writes the ID in the config file. If the identd request arrives after a short while, oidentd will use that ID. Now imagine what happens if 10 quassel users connect at the same time... all identd requests will get the same ID of the quassel user who initiated the connect last. This can be a major problem in particular in those scenarios where one actually needs identd, for example for a Quakenet trust.

This is not actually the case for oidentd... the config file supports entries of the following format, where localport and destport are port ranges:

to <host> lport <localport> from <boundip> fport <destport> {

<capability directive>
}

It should be easy for Quassel to write an entry of the following format for each identity a user has configured, and then ensure that outgoing connections using that identity use a source port in the given port range (in fact, the oidentd config file would only need to be changed when a user created, deleted or edited an identity):

lport 44000:44020 {
    reply "userident" 
}