add an identd key to WEBIRC options
#513
Conversation
| @@ -47,6 +47,7 @@ These options are defined and may be sent by clients while connecting: | |||
| - `local-port=<port>`: This flag indicates the port the gateway accepted the client connection on (e.g. `6697`, `6667`). | |||
| - `certfp-<algo>=<fingerprint>`: This flag indicates the TLS client certificate fingerprint supplied to the WebIRC gateway by the user's actual client application. | |||
| - `spkifp-<algo>=<fingerprint>`: This flag indicates the public key fingerprint for the TLS client certificate supplied to the WebIRC gateway by the user's actual client application. | |||
| - `identd=<identd-response>`: This flag indicates the gateway has done an [ident lookup](https://en.wikipedia.org/wiki/Ident_protocol) and received a response, which it is passing on to the IRCd. | |||
There was a problem hiding this comment.
identd here was chosen because it feels like ident alone might be confused for the first USER parameter, but i'm willing to bikeshed this bit
|
I disapprove of ident, but this change seems fine. |
|
I don't think this is necessary (in 2023 gateways should be giving users their own IPv6 and not using insecure protocols like ident) and we will be ignoring it (most of our users don't even have ident support enabled and we discourage its use) but I don't really have any objection with the key existing as long as its not mandatory to do anything with it. |
i tend to agree that it's a poor solution for what it's used for, but i also recognise that there isn't a workable alternative right this second. i hope one-ipv6-per-user becomes more ubiquitous, but as it stands this small spec tweak will help plumb two existing things together |
|
Bikeshed: an alternative to this would be some kind of unique identifier field which may or may not correlate to an identd response depending on implementation. |
the motivation behind this is the IRCd can't do this lookup itself; an ident lookup must come from the IP to which the end user is connecting, which means the gateway has to be the one to do it.
libera.chat relies on ident responses to be able to confidently ban individual users on shared hosts; otherwise we'd have to ban
~ident, which will only hold until a user changes what they send inUSER