Hi Brett!
Am 14.08.2012 um 16:31 schrieb Brett Smith brett@w3.org:
First, users who have passwords with spaces in them can't connect. If I've done my homework right, this seems to be a limitation of the IRC protocol itself: when clients connect, they provide all their important information (nick, username, password, etc.) on a space-separated line, so the server has no choice but to parse a password with spaces as multiple fields. Do I have that right? I'd be happy to be told I'm wrong about this if it means I can accommodate these users better.
No: the PASS command takes one parameter, the syntax is "PASS <password>". But in the IRC protocol, one parameter containing spaces can be passed to the server: you have to prefix it with the ":" character. So the following is completely "legal":
PASS :a nice password
And I don't think that there is a limitation in ngIRCd preventing passwords with spaces from working "per se", but I didn't test …
On the other hand, I easily can imagine that this is a client bug, and the client is sending something line "PASS a nice password" which is … wrong.
Which client are you using?
Second, ngIRCd allocates 21 bytes for the password buffer, which is too short for some of our users' passwords. As far as I can tell, a maximum password length isn't defined in the RFC or similar, so I'm guessing this limitation is largely historical. I've patched ngIRCd locally to #define CLIENT_PASS_LEN to 64, which seems to be working with no ill effects.
The only "ill" effect is that each client in the network now requires 43 bytes more RAM. This may be a problem or not.
Would you be willing to consider a patch like this upstream? We'd love to be running stock ngIRCd without any patches, even one as trivial as this.
I'm not sure if "just make the buffer bigger" is the right approach: on the one hand, ngIRCd only needs the password while registering the client in the network, and lots of clients not even send any.
And by looking at the code I wonder why we save the password in the CLIENT structure at all: I don't think that a local daemon ever gets a password from a remote client!?
So I think the best would be to move the password file into the CONN structure, and probably make it dynamic using malloc() when needed …
Regards Alex