Installing a scoped npm package with thelounge install lead to an error,
because the original split that was used to split the version from the
package, split at the first @ from scoped packages.
Some servers (e.g. InspIRCd v4) support the concept of a real username,
i.e. the username that was originally sent as distinct from their virtual
username set by services.
Closes: https://github.com/thelounge/thelounge/issues/4900
A user on IRC reported a bug where the topic would change to ":hello"
when the topic was modified to "hello" via the channel topic edit field.
The reason is that irc-framework also sanitizes /RAW commands
and hence our manually escaped trailing param gets another ":"
(which I'm not exactly sure it should be doing... /raw means raw
in my world, but oh well).
We do have a proper /topic command a user could be using, so the
fix is to just do that in the input box as well.
The framework may emit messages which do not have a time stamp.
We tried to unconditionally convert the time field, fix that.
The Msg constructor replaces falsey time fields with the current
date so we can also remove the duplication from that codepath.
There's a bunch of sub optimal behavior from our ident server.
For one, it allows user enumeration which we don't really want and it doesn't clean up connections that don't send any data.
Fix that
We only respond once to data, then half-close the connection.
Hence, we should only listen to a single data event as well,
else if the remote doesn't stop sending data we keep trying to
write to the closed write end of the pipe.
Per RFC 1413, The uniquely identifying tuple includes not only the ports,
but also both addresses.
If multiple connections happen to use the same local port number
(which is possible if the addresses differ), the username of the first
is returned for all, resulting in the wrong ident for all but the
first.
By not checking the connection address, the information becomes
public. Because there is only relatively small number of local ports,
and the remote ports are likely to be either 6667 or 6697, it becomes
trivial to enumerate all the users.
Co-Authored-By: Juerd Waalboer <juerd@tnx.nl>
