1 version=pmwiki-2.3.20 ordered=1 urlencoded=1
2 agent=w3m/0.5.3+git20230121
13 author:1686341988=jrmu
14 diff:1686341988:1686341279:=1c1,512%0a%3c (:delete:)%0a---%0a> ngircd sins%0a> %0a> ngircd's issues, but scored in the style of CinemaSins.%0a> %0a> it was jan6's idea! blame him not me!%0a> %0a> * PENDING - partially fixed, may need testing%0a> * RESOLVED - no longer an issue, no explicit fix%0a> * FIXED - completely fixed%0a> %0a> open issues are worth 1 sin, resolved/fixed are 0.5. the sin counter is%0a> currently at 48.%0a> %0a> Table of Contents%0a> %0a> * 1. PENDING -lines cannot see through cloaks%0a> + 1.1. RESOLVED automatic cloaking via umode +x happens after connect%0a> snote%0a> * 2. no far-connect snotes%0a> * 3. mandatory cloaking is broken%0a> * 4. no statusmsg%0a> * 5. bad separation between local and remote users%0a> + 5.1. auto-opping opers option causes constant desyncs%0a> + 5.2. attempts to cloak remote users%0a> * 6. sends automated invalid mode lines%0a> * 7. no TARGMAX in ISUPPORT line%0a> * 8. ISUPPORT MODES is not enforced%0a> * 9. -lines have a duration in seconds without allowing units%0a> * 10. no SASL%0a> * 11. "minimalism" as an excuse to only implement dumb (unused rfc)%0a> features%0a> + 11.1. no server-side aliases%0a> + 11.2. too many useless channel-types and status modes%0a> + 11.3. PingTimeout and PongTimeout options pointlessly split%0a> * 12. real hostnames are not propagated%0a> * 13. override is not toggleable for opers%0a> * 14. casing not normalized for channel names%0a> * 15. list output is not throttled (ISUPPORT SAFELIST)%0a> * 16. remote list%0a> * 17. CONNECT does not stop when a server is already on the network%0a> * 18. snotes not filterable%0a> * 19. pegs the cpu after running out of file descriptors%0a> * 20. no SIDs/UIDs%0a> * 21. no timestamps%0a> * 22. no RESVs%0a> * 23. no default channel modes%0a> * 24. corrupted modes get set and then cannot be unset, line corruption%0a> * 25. targets occasionally seem to get mixed up%0a> * 26. it occasionally forgets to propagate a user%0a> + 26.1. nick collisions are not checked on nick change%0a> + 26.2. non-existent ghost clients can be created%0a> * 27. list-mode limits are not applied to servers%0a> * 28. no WHOX support%0a> * 29. WHOIS wildcards%0a> * 30. PRIVMSG allows normal users to message partial masks%0a> * 31. allows any user to set umode +s%0a> * 32. status modes and channel types conflict%0a> * 33. services removing a vhost breaks WHO%0a> * 34. NUL char makes ngircd stop reading without an error%0a> * 35. no minimum duration before allowing quit/part messages%0a> * 36. sends incorrect error numerics%0a> * 37. INVITE not well sanitized%0a> * 38. FIXED allows spaces in +k channel key%0a> * 39. sendq limit not configurable%0a> * 40. server to server (s2s) issues%0a> + 40.1. allows any server to change remote users' metadata without a%0a> u-line%0a> + 40.2. relays illegal operations before crashing%0a> o 40.2.1. servers can set themselves a "nickname" without periods%0a> %0a> 1. PENDING -lines cannot see through cloaks%0a> %0a> this makes g-lines and k-lines etc borderline useless^1, since one could%0a> connect to another server without cloaking to evade a g-line on a cloak and%0a> vice versa%0a> %0a> [2022-12-17 Sat]: a fix by hello-smile6 was merged. further testing for%0a> behavior with mandatory cloaking is needed, which may be difficult.%0a> %0a> 1.1. RESOLVED automatic cloaking via umode +x happens after connect snote%0a> %0a> since -lines cannot see through cloaks, these issues combined mean open proxy%0a> monitors that use connect snotes to see ips, such as HOPM, cannot ban people%0a> via -lines until next time they connect.%0a> %0a> [2022-12-17 Sat]: race condition no longer matters for hopm -lines, see%0a> above.%0a> %0a> 2. no far-connect snotes%0a> %0a> this means that to run an open proxy monitor, you will have to put one on%0a> every single server.%0a> %0a> 3. mandatory cloaking is broken%0a> %0a> this type of cloaking, unlike umode +x cloaking, does not break HOPM. however%0a> it just does not work at all on recent ngircd versions^2.%0a> %0a> even if this was not broken, there is the obvious drawback of it being%0a> mandatory.%0a> %0a> 4. no statusmsg%0a> %0a> statusmsg is a feature that allows users to send a message only to people%0a> with status modes (ie ops, voice, etc). among other uses, this allows ops to%0a> discuss matters in private without a separate and redundant "ops channel".%0a> additionally, on ircd's that allow unprivileged use of statusmsg, it can be%0a> used to report stuff to ops instead of playing the is the op i pmmed present?%0a> roulette.%0a> %0a> 5. bad separation between local and remote users%0a> %0a> ngircd seemingly treating remote users the same as local ones causes a number%0a> of issues.%0a> %0a> 5.1. auto-opping opers option causes constant desyncs%0a> %0a> when an oper on a server with this option disabled joins a +P channel, a%0a> downstream server with this enabled will op them anyways, without telling the%0a> upstream server, causing modes to be desynced.%0a> %0a> to be fair, this one could be avoided by simply disabling the option.%0a> %0a> 5.2. attempts to cloak remote users%0a> %0a> this had "logic" (cloak only if there is a : or . in the hostname) for%0a> preventing remote already-cloaked users from getting cloaked again, but it is%0a> Sometimes broken, going as far as giving the complete opposite result on some%0a> versions^2.%0a> %0a> however, why is this an issue in the first place? just do not cloak remote%0a> users, it is not hard.%0a> %0a> 6. sends automated invalid mode lines%0a> %0a> for example, from a netjoin:%0a> %0a> :irc.shelltalk.net MODE #offtopic +ao ChanServ%0a> %0a> the parameter for +o is missing, which is not allowed.%0a> %0a> it does this for bursted status modes during a netjoin, and possibly^when?%0a> during the auto-opping of opers in +P channels.%0a> %0a> 7. no TARGMAX in ISUPPORT line%0a> %0a> how many targets can your line be sent to? no clue, at least 20, but its%0a> equally probable there is no limit at all!%0a> %0a> 8. ISUPPORT MODES is not enforced%0a> %0a> how many modes can you actually set in one line? no clue, somewhere around%0a> 13!%0a> %0a> 9. -lines have a duration in seconds without allowing units%0a> %0a> only relying on seconds gets unwieldy fast, a year is a massive 31557600!%0a> other ircd's either allow units or use minutes.%0a> %0a> 10. no SASL%0a> %0a> sasl is the only reproducible and machine readable way to ensure%0a> authentication with services. without it, you are forced to either%0a> authenticate blindly or use fragile (and services package dependent) pattern%0a> matching for automated authentication.%0a> %0a> 11. "minimalism" as an excuse to only implement dumb (unused rfc) features%0a> %0a> the community wants a feature such as server-side aliases? NO! this is a%0a> mInImAlIsT ircd! we only implement features that nobody has used in the past%0a> two decades like server-local and unmoderated channels, because it's in MuH%0a> rFc!%0a> %0a> 11.1. no server-side aliases%0a> %0a> such as /NS, which the majority of clients expect to be there%0a> %0a> 11.2. too many useless channel-types and status modes%0a> %0a> so much for "minimalism". saying these obsolete & 'non-propagated' and +%0a> 'modeless' channel types have not been used by anyone except hello-smile6 for%0a> the past two decades would not be too large an exaggeration.%0a> %0a> status modes other than +o op and +v voice are unnecessary. maybe keep +h%0a> halfop too if you wish to be indulgent. but if you find yourself wanting even%0a> more granularity than that, like +a admin and +q owner, use services. or%0a> perhaps just stop micro-managing your channel ops.%0a> %0a> perhaps including + 'modeless' channels was an impressive feat of foresight%0a> to lessen the impact of ngircd's rampent mode corruption. lol.%0a> %0a> 11.3. PingTimeout and PongTimeout options pointlessly split%0a> %0a> rather than a single ping timeout option like most ircds, ngircd splits this%0a> into two separate options. PingTimeout is the time before sending a PING,%0a> while PongTimeout is the grace period before disconnecting a non-responding%0a> client.%0a> %0a> having the values for PingTimeout and PongTimeout be different is basically%0a> pointless. if PongTimeout is longer than PingTimeout, it wastes more%0a> bandwidth for nearly the same amount of time to disconnect dead clients.%0a> conversely, if PingTimeout is longer than Pongtimeout, it decreases the%0a> predictability and consistency of the time to disconnect dead clients.%0a> %0a> 12. real hostnames are not propagated%0a> %0a> this means you have to send a network-intensive remote WHOIS line every time%0a> you need to see through a cloak. this is part of why working around the%0a> cloaking and HOPM issues without creating a massive ddos vector is so%0a> difficult.%0a> %0a> 13. override is not toggleable for opers%0a> %0a> override being always-on means opers can accidentally do things they aren't%0a> supposed to, like joining an invite-only channel without an invite/invex.%0a> conversely, normalizing this means actual oper abuse will be written off as%0a> an accident, removing any accountability.%0a> %0a> 14. casing not normalized for channel names%0a> %0a> you get whatever casing each person used when joining as the target for%0a> receiving messages etc.%0a> %0a> this is especially a problem for older clients which (incorrectly) assume%0a> rfc1459 casing without checking ISUPPORT CASEMAPPING, instead of the ascii%0a> casing ngircd uses, possibly causing messages to end up in the wrong place.%0a> %0a> 15. list output is not throttled (ISUPPORT SAFELIST)%0a> %0a> this means that if there are a sufficient number of channels, and your%0a> internet connection is not up to the task, running /list will disconnect you.%0a> %0a> 16. remote list%0a> %0a> you can ask a remote server for the channel list, and it will send it over%0a> s2s, causing a massive DDoS vector. why does this even exist? nobody knows!^3%0a> %0a> on the upside, the added overhead of going through s2s means it will go slow%0a> enough to usually not flood you off.%0a> %0a> 17. CONNECT does not stop when a server is already on the network%0a> %0a> if you CONNECT server.that.is.already.here, it will keep making connection%0a> attempts, flooding snotes and logs with 'already linked' errors until you%0a> manually intervene.%0a> %0a> it appears to eventually stop on its own, though when or what causes it to%0a> stop is not known.%0a> %0a> 18. snotes not filterable%0a> %0a> you can only choose between +c (local connection snotes) and/or +s%0a> (everything else)%0a> %0a> 19. pegs the cpu after running out of file descriptors%0a> %0a> instead of, say, just not accepting any more connections, it uses up all the%0a> cpu until it cannot keep up.%0a> %0a> 20. no SIDs/UIDs%0a> %0a> this means proper tracking of users via pseudoservers can break and there is%0a> nothing guaranteed to be an unused fallback nick on collisions.%0a> %0a> 21. no timestamps%0a> %0a> timestamps allow for proper remediation of network state after a netjoin.%0a> ngircd currently just mashes together conflicting state, which will (among%0a> other issues) just randomly give people op.%0a> %0a> 22. no RESVs%0a> %0a> there is no reasonable way to disallow using a nickname^4, despite that there%0a> is literally a list of services nicknames in the config.%0a> %0a> for a more outlandish solution, you could probably make a pseudoserver with a%0a> nickname of the reserved nickname, since they seem to get stuck in the s2s%0a> state even after the server disconnects, though i hope i do not need to%0a> explain why this is a bad idea… or maybe use one of those ghost users…%0a> %0a> 23. no default channel modes%0a> %0a> without sane default channel modes like +nt, anyone is able to send messages%0a> to a channel without being in it, and is able to set the topic.%0a> %0a> 24. corrupted modes get set and then cannot be unset, line corruption%0a> %0a> channel modes occasionally appear to somehow get corrupted^how?^5 seemingly%0a> by mixing together lines, leaving the channel with a bunch of unknown mode%0a> characters that ngircd does not allow removing.%0a> %0a> for example, after a netjoin, a channel gained the modes +rntMODE#sic/p@1gk¡P%0a> cxc¡y:irc, and out of those, only +ntMOsikP * are known ones^6 that clients%0a> are allowed to unset.%0a> %0a> similar (the same?) 'corruption' happens when ngircd does stuff with any tcp%0a> connection, especially under high traffic like during a netjoin, even%0a> occasionally when sending the motd to a client, however modes seems to be the%0a> most susceptible.%0a> %0a> 25. targets occasionally seem to get mixed up%0a> %0a> [2022-11-17 Thu]: when or why this happens is unclear at the moment%0a> %0a> ngircd will occasionally send lines to the wrong targets, for example sending%0a> someone's JOIN to people not in the channel they joined. this breaks clients%0a> attempting to track irc state.%0a> %0a> 26. it occasionally forgets to propagate a user%0a> %0a> this means messages from the user will be ignored by some servers and, if%0a> someone else uses the same nickname, they can simultaniously be on the same%0a> nick (for some reason, it will not collide when this happens)%0a> %0a> 26.1. nick collisions are not checked on nick change%0a> %0a> multiple people on the same nick will propagation problems, since there are%0a> no user ids, and may even create ghost clients that never disconnect.%0a> %0a> this may be used, by a regular user without any elevated privileges, to%0a> shadowban another user's nickname. preventing any of their messages from%0a> propagating because ngircd silently drops s2s with the 'wrong' source.%0a> %0a> 26.2. non-existent ghost clients can be created%0a> %0a> these clients not tied to a real connection will not leave on their own,%0a> similar to my sister's ex.%0a> %0a> 27. list-mode limits are not applied to servers%0a> %0a> this means, for example, a user can continue to apply bans forever using%0a> services, breaking attempts to list the modes or netjoin.%0a> %0a> this possibly could contribute to modes getting corrupted via some sort of%0a> overflow, or just by increasing the netjoin burst size too much.%0a> %0a> this sometimes also seems to result in a crash.%0a> %0a> while fixing this would result in desyncs, having at least some hard limit%0a> for list-mode length would greatly improve stability when netjoining, and%0a> would almost certainly make ngircd's traffic corruption issues less%0a> noticable.%0a> %0a> 28. no WHOX support%0a> %0a> WHOX would allow clients (especially bots with account-tracking) to have a%0a> better idea of irc state.%0a> %0a> 29. WHOIS wildcards%0a> %0a> why does WHOIS * exist? nobody knows!%0a> %0a> 30. PRIVMSG allows normal users to message partial masks%0a> %0a> it'll message a single random client that matches.%0a> %0a> what? what possible use could this have?%0a> %0a> PRIVMSG *!ident :hi there%0a> %0a> 31. allows any user to set umode +s%0a> %0a> this allows anyone to see snotes, which includes -lines being set and failed%0a> oper attempts.%0a> %0a> it is worth noting that this was probably not an oversight, since umode +c%0a> (connection snotes) does require oper to set. perhaps this is for%0a> "transparency" or similar.%0a> %0a> 32. status modes and channel types conflict%0a> %0a> this means WHOIS output of which channels someone is in will be ambiguous. an%0a> entry of +#chaos could either mean they have voice in #chaos, or that they%0a> are in a channel called +#chaos without any status modes.%0a> %0a> this also makes implementing statusmsg on current ngircd impossible%0a> %0a> 33. services removing a vhost breaks WHO%0a> %0a> some services packages will set a hostname to a space when disabling a vhost,%0a> since it expects the ircd to just fallback to the real hostname. ngircd does%0a> not.%0a> %0a> when a user's hostname is nothing, ngircd will produce WHO and WHOIS%0a> responses with the wrong number of parameters, as irc is a space-deliminated%0a> protocol.%0a> %0a> 34. NUL char makes ngircd stop reading without an error%0a> %0a> while what should be done when receiving a NUL is undefined behavior, it is%0a> safe to say it should probably not be this. interestingly, ngircd will still%0a> keep the connection open and continue sending the client lines, it just stops%0a> reading. at least, until you inevitably ping timeout.%0a> %0a> 35. no minimum duration before allowing quit/part messages%0a> %0a> limiting the use of quit and part messages for short-lived connections will%0a> protect against some rudimentary spambots.%0a> %0a> 36. sends incorrect error numerics%0a> %0a> when multiple chat-restricting modes are set, a client only affected by some%0a> of those modes may receive an error numeric referencing a mode that should%0a> not affect them.%0a> %0a> for example, in a channel with +M (only users identified with services may%0a> speak) and +m (only voiced users may speak), a client will receive 477 "You%0a> need to be identified to a registered account to message this channel" rather%0a> than 404 "Cannot send to channel" when sending a message even if identified.%0a> %0a> 37. INVITE not well sanitized%0a> %0a> most ircd's only allow inviting people to channels you are in. ngircd on the%0a> other hand allows mostly arbitrary text. this allows you to invite people to%0a> 0 (the magic part-from-everywhere-else channel), fun.%0a> %0a> 38. FIXED allows spaces in +k channel key%0a> %0a> this results in invalid mode lines sent to everyone in the channel, and most%0a> clients will be very confused if they try to join using the key.%0a> %0a> > MODE #channel +k :meow rawr%0a> %3c :xfnwtest!~xfnwtest@2600:4040:2c6f:2200::212 MODE #channel +k meow rawr%0a> > MODE #channel%0a> %3c :irc.freeirc.org 324 xfnwtest #channel +k meow rawr%0a> %3c :irc.freeirc.org 329 xfnwtest #channel 1671730265%0a> %0a> [2021-09-05 Sun]: reported by Val Lorentz%0a> %0a> [2023-01-02 Mon]: fixed in commit 8e9c789a%0a> %0a> 39. sendq limit not configurable%0a> %0a> the send queue (or as ngircd calls it, the writebuffer) is where lines pile%0a> up when the client is not accepting them fast enough.%0a> %0a> the hardcoded values of 32K and 64K for clients and servers respectively are%0a> tiny, only enough for 64 lines for a client and 128 for servers; you will%0a> disconnect if you look at it wrong. this plus the lack of SAFELIST means you%0a> are pretty much guaranteed to get flooded off for running /list.%0a> %0a> 400K for clients, 1M for opers, and 4M for servers would be much saner values%0a> ^7, though it should be configurable (ideally per "connection class" even,%0a> but ngircd does not support those)%0a> %0a> 40. server to server (s2s) issues%0a> %0a> these are perhaps less important if your network is unified.%0a> %0a> 40.1. allows any server to change remote users' metadata without a u-line%0a> %0a> including nickname, usermodes, and other info shown in /whois%0a> %0a> there is literally no good reason to allow non-ulined servers to do this, and%0a> is just asking for someone to accidentally link two services servers.%0a> %0a> 40.2. relays illegal operations before crashing%0a> %0a> the appropriate response would be to SQUIT the server sending those, not%0a> relay it and cause the entire network to crash.%0a> %0a> even if you were fine with it crashing^8, relaying an illegal operation to%0a> other servers is unacceptable.%0a> %0a> 40.2.1. servers can set themselves a "nickname" without periods%0a> %0a> server names are differentiated from users by containing periods (. also%0a> known as full stop). allowing said periods to be removed means clients can no%0a> longer tell something is a server, breaking stored state, and if you interact%0a> with it wrong the entire network crashes.%0a> %0a> there is really no reason for allowing setting nicknames on servers.%0a> %0a> Footnotes:%0a> %0a> ^1%0a> %0a> unless you make multiple%0a> %0a> ^2%0a> %0a> possibly only on openbsd%0a> %0a> ^3%0a> %0a> it has been suggested, but not confirmed, that remote list is intended for%0a> seeing the 'local channels' on another server%0a> %0a> ^4%0a> %0a> note ngircd's -lines allow a nickname field, however these appear to not be%0a> matched on connect%0a> %0a> ^5%0a> %0a> perhaps this is a result of the sendq buffer overflowing, thread unsafety, or%0a> partially read lines?%0a> %0a> ^6%0a> %0a> note that +r is an unknown channel mode transparently set by some services,%0a> so it's presence is expected%0a> %0a> ^7%0a> %0a> you guessed it, sane values stolen right from solanum's example config, lol%0a> %0a> ^8%0a> %0a> solanum's devs say crashing on illegal s2s is "fine" because server links%0a> should be only given to trustworthy servers%0a> %0a
15 host:1686341988=38.87.162.8
16 author:1686341279=jrmu
17 csum:1686341279=by xfnw
18 diff:1686341279:1686341279:=1,512d0%0a%3c ngircd sins%0a%3c %0a%3c ngircd's issues, but scored in the style of CinemaSins.%0a%3c %0a%3c it was jan6's idea! blame him not me!%0a%3c %0a%3c * PENDING - partially fixed, may need testing%0a%3c * RESOLVED - no longer an issue, no explicit fix%0a%3c * FIXED - completely fixed%0a%3c %0a%3c open issues are worth 1 sin, resolved/fixed are 0.5. the sin counter is%0a%3c currently at 48.%0a%3c %0a%3c Table of Contents%0a%3c %0a%3c * 1. PENDING -lines cannot see through cloaks%0a%3c + 1.1. RESOLVED automatic cloaking via umode +x happens after connect%0a%3c snote%0a%3c * 2. no far-connect snotes%0a%3c * 3. mandatory cloaking is broken%0a%3c * 4. no statusmsg%0a%3c * 5. bad separation between local and remote users%0a%3c + 5.1. auto-opping opers option causes constant desyncs%0a%3c + 5.2. attempts to cloak remote users%0a%3c * 6. sends automated invalid mode lines%0a%3c * 7. no TARGMAX in ISUPPORT line%0a%3c * 8. ISUPPORT MODES is not enforced%0a%3c * 9. -lines have a duration in seconds without allowing units%0a%3c * 10. no SASL%0a%3c * 11. "minimalism" as an excuse to only implement dumb (unused rfc)%0a%3c features%0a%3c + 11.1. no server-side aliases%0a%3c + 11.2. too many useless channel-types and status modes%0a%3c + 11.3. PingTimeout and PongTimeout options pointlessly split%0a%3c * 12. real hostnames are not propagated%0a%3c * 13. override is not toggleable for opers%0a%3c * 14. casing not normalized for channel names%0a%3c * 15. list output is not throttled (ISUPPORT SAFELIST)%0a%3c * 16. remote list%0a%3c * 17. CONNECT does not stop when a server is already on the network%0a%3c * 18. snotes not filterable%0a%3c * 19. pegs the cpu after running out of file descriptors%0a%3c * 20. no SIDs/UIDs%0a%3c * 21. no timestamps%0a%3c * 22. no RESVs%0a%3c * 23. no default channel modes%0a%3c * 24. corrupted modes get set and then cannot be unset, line corruption%0a%3c * 25. targets occasionally seem to get mixed up%0a%3c * 26. it occasionally forgets to propagate a user%0a%3c + 26.1. nick collisions are not checked on nick change%0a%3c + 26.2. non-existent ghost clients can be created%0a%3c * 27. list-mode limits are not applied to servers%0a%3c * 28. no WHOX support%0a%3c * 29. WHOIS wildcards%0a%3c * 30. PRIVMSG allows normal users to message partial masks%0a%3c * 31. allows any user to set umode +s%0a%3c * 32. status modes and channel types conflict%0a%3c * 33. services removing a vhost breaks WHO%0a%3c * 34. NUL char makes ngircd stop reading without an error%0a%3c * 35. no minimum duration before allowing quit/part messages%0a%3c * 36. sends incorrect error numerics%0a%3c * 37. INVITE not well sanitized%0a%3c * 38. FIXED allows spaces in +k channel key%0a%3c * 39. sendq limit not configurable%0a%3c * 40. server to server (s2s) issues%0a%3c + 40.1. allows any server to change remote users' metadata without a%0a%3c u-line%0a%3c + 40.2. relays illegal operations before crashing%0a%3c o 40.2.1. servers can set themselves a "nickname" without periods%0a%3c %0a%3c 1. PENDING -lines cannot see through cloaks%0a%3c %0a%3c this makes g-lines and k-lines etc borderline useless^1, since one could%0a%3c connect to another server without cloaking to evade a g-line on a cloak and%0a%3c vice versa%0a%3c %0a%3c [2022-12-17 Sat]: a fix by hello-smile6 was merged. further testing for%0a%3c behavior with mandatory cloaking is needed, which may be difficult.%0a%3c %0a%3c 1.1. RESOLVED automatic cloaking via umode +x happens after connect snote%0a%3c %0a%3c since -lines cannot see through cloaks, these issues combined mean open proxy%0a%3c monitors that use connect snotes to see ips, such as HOPM, cannot ban people%0a%3c via -lines until next time they connect.%0a%3c %0a%3c [2022-12-17 Sat]: race condition no longer matters for hopm -lines, see%0a%3c above.%0a%3c %0a%3c 2. no far-connect snotes%0a%3c %0a%3c this means that to run an open proxy monitor, you will have to put one on%0a%3c every single server.%0a%3c %0a%3c 3. mandatory cloaking is broken%0a%3c %0a%3c this type of cloaking, unlike umode +x cloaking, does not break HOPM. however%0a%3c it just does not work at all on recent ngircd versions^2.%0a%3c %0a%3c even if this was not broken, there is the obvious drawback of it being%0a%3c mandatory.%0a%3c %0a%3c 4. no statusmsg%0a%3c %0a%3c statusmsg is a feature that allows users to send a message only to people%0a%3c with status modes (ie ops, voice, etc). among other uses, this allows ops to%0a%3c discuss matters in private without a separate and redundant "ops channel".%0a%3c additionally, on ircd's that allow unprivileged use of statusmsg, it can be%0a%3c used to report stuff to ops instead of playing the is the op i pmmed present?%0a%3c roulette.%0a%3c %0a%3c 5. bad separation between local and remote users%0a%3c %0a%3c ngircd seemingly treating remote users the same as local ones causes a number%0a%3c of issues.%0a%3c %0a%3c 5.1. auto-opping opers option causes constant desyncs%0a%3c %0a%3c when an oper on a server with this option disabled joins a +P channel, a%0a%3c downstream server with this enabled will op them anyways, without telling the%0a%3c upstream server, causing modes to be desynced.%0a%3c %0a%3c to be fair, this one could be avoided by simply disabling the option.%0a%3c %0a%3c 5.2. attempts to cloak remote users%0a%3c %0a%3c this had "logic" (cloak only if there is a : or . in the hostname) for%0a%3c preventing remote already-cloaked users from getting cloaked again, but it is%0a%3c Sometimes broken, going as far as giving the complete opposite result on some%0a%3c versions^2.%0a%3c %0a%3c however, why is this an issue in the first place? just do not cloak remote%0a%3c users, it is not hard.%0a%3c %0a%3c 6. sends automated invalid mode lines%0a%3c %0a%3c for example, from a netjoin:%0a%3c %0a%3c :irc.shelltalk.net MODE #offtopic +ao ChanServ%0a%3c %0a%3c the parameter for +o is missing, which is not allowed.%0a%3c %0a%3c it does this for bursted status modes during a netjoin, and possibly^when?%0a%3c during the auto-opping of opers in +P channels.%0a%3c %0a%3c 7. no TARGMAX in ISUPPORT line%0a%3c %0a%3c how many targets can your line be sent to? no clue, at least 20, but its%0a%3c equally probable there is no limit at all!%0a%3c %0a%3c 8. ISUPPORT MODES is not enforced%0a%3c %0a%3c how many modes can you actually set in one line? no clue, somewhere around%0a%3c 13!%0a%3c %0a%3c 9. -lines have a duration in seconds without allowing units%0a%3c %0a%3c only relying on seconds gets unwieldy fast, a year is a massive 31557600!%0a%3c other ircd's either allow units or use minutes.%0a%3c %0a%3c 10. no SASL%0a%3c %0a%3c sasl is the only reproducible and machine readable way to ensure%0a%3c authentication with services. without it, you are forced to either%0a%3c authenticate blindly or use fragile (and services package dependent) pattern%0a%3c matching for automated authentication.%0a%3c %0a%3c 11. "minimalism" as an excuse to only implement dumb (unused rfc) features%0a%3c %0a%3c the community wants a feature such as server-side aliases? NO! this is a%0a%3c mInImAlIsT ircd! we only implement features that nobody has used in the past%0a%3c two decades like server-local and unmoderated channels, because it's in MuH%0a%3c rFc!%0a%3c %0a%3c 11.1. no server-side aliases%0a%3c %0a%3c such as /NS, which the majority of clients expect to be there%0a%3c %0a%3c 11.2. too many useless channel-types and status modes%0a%3c %0a%3c so much for "minimalism". saying these obsolete & 'non-propagated' and +%0a%3c 'modeless' channel types have not been used by anyone except hello-smile6 for%0a%3c the past two decades would not be too large an exaggeration.%0a%3c %0a%3c status modes other than +o op and +v voice are unnecessary. maybe keep +h%0a%3c halfop too if you wish to be indulgent. but if you find yourself wanting even%0a%3c more granularity than that, like +a admin and +q owner, use services. or%0a%3c perhaps just stop micro-managing your channel ops.%0a%3c %0a%3c perhaps including + 'modeless' channels was an impressive feat of foresight%0a%3c to lessen the impact of ngircd's rampent mode corruption. lol.%0a%3c %0a%3c 11.3. PingTimeout and PongTimeout options pointlessly split%0a%3c %0a%3c rather than a single ping timeout option like most ircds, ngircd splits this%0a%3c into two separate options. PingTimeout is the time before sending a PING,%0a%3c while PongTimeout is the grace period before disconnecting a non-responding%0a%3c client.%0a%3c %0a%3c having the values for PingTimeout and PongTimeout be different is basically%0a%3c pointless. if PongTimeout is longer than PingTimeout, it wastes more%0a%3c bandwidth for nearly the same amount of time to disconnect dead clients.%0a%3c conversely, if PingTimeout is longer than Pongtimeout, it decreases the%0a%3c predictability and consistency of the time to disconnect dead clients.%0a%3c %0a%3c 12. real hostnames are not propagated%0a%3c %0a%3c this means you have to send a network-intensive remote WHOIS line every time%0a%3c you need to see through a cloak. this is part of why working around the%0a%3c cloaking and HOPM issues without creating a massive ddos vector is so%0a%3c difficult.%0a%3c %0a%3c 13. override is not toggleable for opers%0a%3c %0a%3c override being always-on means opers can accidentally do things they aren't%0a%3c supposed to, like joining an invite-only channel without an invite/invex.%0a%3c conversely, normalizing this means actual oper abuse will be written off as%0a%3c an accident, removing any accountability.%0a%3c %0a%3c 14. casing not normalized for channel names%0a%3c %0a%3c you get whatever casing each person used when joining as the target for%0a%3c receiving messages etc.%0a%3c %0a%3c this is especially a problem for older clients which (incorrectly) assume%0a%3c rfc1459 casing without checking ISUPPORT CASEMAPPING, instead of the ascii%0a%3c casing ngircd uses, possibly causing messages to end up in the wrong place.%0a%3c %0a%3c 15. list output is not throttled (ISUPPORT SAFELIST)%0a%3c %0a%3c this means that if there are a sufficient number of channels, and your%0a%3c internet connection is not up to the task, running /list will disconnect you.%0a%3c %0a%3c 16. remote list%0a%3c %0a%3c you can ask a remote server for the channel list, and it will send it over%0a%3c s2s, causing a massive DDoS vector. why does this even exist? nobody knows!^3%0a%3c %0a%3c on the upside, the added overhead of going through s2s means it will go slow%0a%3c enough to usually not flood you off.%0a%3c %0a%3c 17. CONNECT does not stop when a server is already on the network%0a%3c %0a%3c if you CONNECT server.that.is.already.here, it will keep making connection%0a%3c attempts, flooding snotes and logs with 'already linked' errors until you%0a%3c manually intervene.%0a%3c %0a%3c it appears to eventually stop on its own, though when or what causes it to%0a%3c stop is not known.%0a%3c %0a%3c 18. snotes not filterable%0a%3c %0a%3c you can only choose between +c (local connection snotes) and/or +s%0a%3c (everything else)%0a%3c %0a%3c 19. pegs the cpu after running out of file descriptors%0a%3c %0a%3c instead of, say, just not accepting any more connections, it uses up all the%0a%3c cpu until it cannot keep up.%0a%3c %0a%3c 20. no SIDs/UIDs%0a%3c %0a%3c this means proper tracking of users via pseudoservers can break and there is%0a%3c nothing guaranteed to be an unused fallback nick on collisions.%0a%3c %0a%3c 21. no timestamps%0a%3c %0a%3c timestamps allow for proper remediation of network state after a netjoin.%0a%3c ngircd currently just mashes together conflicting state, which will (among%0a%3c other issues) just randomly give people op.%0a%3c %0a%3c 22. no RESVs%0a%3c %0a%3c there is no reasonable way to disallow using a nickname^4, despite that there%0a%3c is literally a list of services nicknames in the config.%0a%3c %0a%3c for a more outlandish solution, you could probably make a pseudoserver with a%0a%3c nickname of the reserved nickname, since they seem to get stuck in the s2s%0a%3c state even after the server disconnects, though i hope i do not need to%0a%3c explain why this is a bad idea… or maybe use one of those ghost users…%0a%3c %0a%3c 23. no default channel modes%0a%3c %0a%3c without sane default channel modes like +nt, anyone is able to send messages%0a%3c to a channel without being in it, and is able to set the topic.%0a%3c %0a%3c 24. corrupted modes get set and then cannot be unset, line corruption%0a%3c %0a%3c channel modes occasionally appear to somehow get corrupted^how?^5 seemingly%0a%3c by mixing together lines, leaving the channel with a bunch of unknown mode%0a%3c characters that ngircd does not allow removing.%0a%3c %0a%3c for example, after a netjoin, a channel gained the modes +rntMODE#sic/p@1gk¡P%0a%3c cxc¡y:irc, and out of those, only +ntMOsikP * are known ones^6 that clients%0a%3c are allowed to unset.%0a%3c %0a%3c similar (the same?) 'corruption' happens when ngircd does stuff with any tcp%0a%3c connection, especially under high traffic like during a netjoin, even%0a%3c occasionally when sending the motd to a client, however modes seems to be the%0a%3c most susceptible.%0a%3c %0a%3c 25. targets occasionally seem to get mixed up%0a%3c %0a%3c [2022-11-17 Thu]: when or why this happens is unclear at the moment%0a%3c %0a%3c ngircd will occasionally send lines to the wrong targets, for example sending%0a%3c someone's JOIN to people not in the channel they joined. this breaks clients%0a%3c attempting to track irc state.%0a%3c %0a%3c 26. it occasionally forgets to propagate a user%0a%3c %0a%3c this means messages from the user will be ignored by some servers and, if%0a%3c someone else uses the same nickname, they can simultaniously be on the same%0a%3c nick (for some reason, it will not collide when this happens)%0a%3c %0a%3c 26.1. nick collisions are not checked on nick change%0a%3c %0a%3c multiple people on the same nick will propagation problems, since there are%0a%3c no user ids, and may even create ghost clients that never disconnect.%0a%3c %0a%3c this may be used, by a regular user without any elevated privileges, to%0a%3c shadowban another user's nickname. preventing any of their messages from%0a%3c propagating because ngircd silently drops s2s with the 'wrong' source.%0a%3c %0a%3c 26.2. non-existent ghost clients can be created%0a%3c %0a%3c these clients not tied to a real connection will not leave on their own,%0a%3c similar to my sister's ex.%0a%3c %0a%3c 27. list-mode limits are not applied to servers%0a%3c %0a%3c this means, for example, a user can continue to apply bans forever using%0a%3c services, breaking attempts to list the modes or netjoin.%0a%3c %0a%3c this possibly could contribute to modes getting corrupted via some sort of%0a%3c overflow, or just by increasing the netjoin burst size too much.%0a%3c %0a%3c this sometimes also seems to result in a crash.%0a%3c %0a%3c while fixing this would result in desyncs, having at least some hard limit%0a%3c for list-mode length would greatly improve stability when netjoining, and%0a%3c would almost certainly make ngircd's traffic corruption issues less%0a%3c noticable.%0a%3c %0a%3c 28. no WHOX support%0a%3c %0a%3c WHOX would allow clients (especially bots with account-tracking) to have a%0a%3c better idea of irc state.%0a%3c %0a%3c 29. WHOIS wildcards%0a%3c %0a%3c why does WHOIS * exist? nobody knows!%0a%3c %0a%3c 30. PRIVMSG allows normal users to message partial masks%0a%3c %0a%3c it'll message a single random client that matches.%0a%3c %0a%3c what? what possible use could this have?%0a%3c %0a%3c PRIVMSG *!ident :hi there%0a%3c %0a%3c 31. allows any user to set umode +s%0a%3c %0a%3c this allows anyone to see snotes, which includes -lines being set and failed%0a%3c oper attempts.%0a%3c %0a%3c it is worth noting that this was probably not an oversight, since umode +c%0a%3c (connection snotes) does require oper to set. perhaps this is for%0a%3c "transparency" or similar.%0a%3c %0a%3c 32. status modes and channel types conflict%0a%3c %0a%3c this means WHOIS output of which channels someone is in will be ambiguous. an%0a%3c entry of +#chaos could either mean they have voice in #chaos, or that they%0a%3c are in a channel called +#chaos without any status modes.%0a%3c %0a%3c this also makes implementing statusmsg on current ngircd impossible%0a%3c %0a%3c 33. services removing a vhost breaks WHO%0a%3c %0a%3c some services packages will set a hostname to a space when disabling a vhost,%0a%3c since it expects the ircd to just fallback to the real hostname. ngircd does%0a%3c not.%0a%3c %0a%3c when a user's hostname is nothing, ngircd will produce WHO and WHOIS%0a%3c responses with the wrong number of parameters, as irc is a space-deliminated%0a%3c protocol.%0a%3c %0a%3c 34. NUL char makes ngircd stop reading without an error%0a%3c %0a%3c while what should be done when receiving a NUL is undefined behavior, it is%0a%3c safe to say it should probably not be this. interestingly, ngircd will still%0a%3c keep the connection open and continue sending the client lines, it just stops%0a%3c reading. at least, until you inevitably ping timeout.%0a%3c %0a%3c 35. no minimum duration before allowing quit/part messages%0a%3c %0a%3c limiting the use of quit and part messages for short-lived connections will%0a%3c protect against some rudimentary spambots.%0a%3c %0a%3c 36. sends incorrect error numerics%0a%3c %0a%3c when multiple chat-restricting modes are set, a client only affected by some%0a%3c of those modes may receive an error numeric referencing a mode that should%0a%3c not affect them.%0a%3c %0a%3c for example, in a channel with +M (only users identified with services may%0a%3c speak) and +m (only voiced users may speak), a client will receive 477 "You%0a%3c need to be identified to a registered account to message this channel" rather%0a%3c than 404 "Cannot send to channel" when sending a message even if identified.%0a%3c %0a%3c 37. INVITE not well sanitized%0a%3c %0a%3c most ircd's only allow inviting people to channels you are in. ngircd on the%0a%3c other hand allows mostly arbitrary text. this allows you to invite people to%0a%3c 0 (the magic part-from-everywhere-else channel), fun.%0a%3c %0a%3c 38. FIXED allows spaces in +k channel key%0a%3c %0a%3c this results in invalid mode lines sent to everyone in the channel, and most%0a%3c clients will be very confused if they try to join using the key.%0a%3c %0a%3c > MODE #channel +k :meow rawr%0a%3c %3c :xfnwtest!~xfnwtest@2600:4040:2c6f:2200::212 MODE #channel +k meow rawr%0a%3c > MODE #channel%0a%3c %3c :irc.freeirc.org 324 xfnwtest #channel +k meow rawr%0a%3c %3c :irc.freeirc.org 329 xfnwtest #channel 1671730265%0a%3c %0a%3c [2021-09-05 Sun]: reported by Val Lorentz%0a%3c %0a%3c [2023-01-02 Mon]: fixed in commit 8e9c789a%0a%3c %0a%3c 39. sendq limit not configurable%0a%3c %0a%3c the send queue (or as ngircd calls it, the writebuffer) is where lines pile%0a%3c up when the client is not accepting them fast enough.%0a%3c %0a%3c the hardcoded values of 32K and 64K for clients and servers respectively are%0a%3c tiny, only enough for 64 lines for a client and 128 for servers; you will%0a%3c disconnect if you look at it wrong. this plus the lack of SAFELIST means you%0a%3c are pretty much guaranteed to get flooded off for running /list.%0a%3c %0a%3c 400K for clients, 1M for opers, and 4M for servers would be much saner values%0a%3c ^7, though it should be configurable (ideally per "connection class" even,%0a%3c but ngircd does not support those)%0a%3c %0a%3c 40. server to server (s2s) issues%0a%3c %0a%3c these are perhaps less important if your network is unified.%0a%3c %0a%3c 40.1. allows any server to change remote users' metadata without a u-line%0a%3c %0a%3c including nickname, usermodes, and other info shown in /whois%0a%3c %0a%3c there is literally no good reason to allow non-ulined servers to do this, and%0a%3c is just asking for someone to accidentally link two services servers.%0a%3c %0a%3c 40.2. relays illegal operations before crashing%0a%3c %0a%3c the appropriate response would be to SQUIT the server sending those, not%0a%3c relay it and cause the entire network to crash.%0a%3c %0a%3c even if you were fine with it crashing^8, relaying an illegal operation to%0a%3c other servers is unacceptable.%0a%3c %0a%3c 40.2.1. servers can set themselves a "nickname" without periods%0a%3c %0a%3c server names are differentiated from users by containing periods (. also%0a%3c known as full stop). allowing said periods to be removed means clients can no%0a%3c longer tell something is a server, breaking stored state, and if you interact%0a%3c with it wrong the entire network crashes.%0a%3c %0a%3c there is really no reason for allowing setting nicknames on servers.%0a%3c %0a%3c Footnotes:%0a%3c %0a%3c ^1%0a%3c %0a%3c unless you make multiple%0a%3c %0a%3c ^2%0a%3c %0a%3c possibly only on openbsd%0a%3c %0a%3c ^3%0a%3c %0a%3c it has been suggested, but not confirmed, that remote list is intended for%0a%3c seeing the 'local channels' on another server%0a%3c %0a%3c ^4%0a%3c %0a%3c note ngircd's -lines allow a nickname field, however these appear to not be%0a%3c matched on connect%0a%3c %0a%3c ^5%0a%3c %0a%3c perhaps this is a result of the sendq buffer overflowing, thread unsafety, or%0a%3c partially read lines?%0a%3c %0a%3c ^6%0a%3c %0a%3c note that +r is an unknown channel mode transparently set by some services,%0a%3c so it's presence is expected%0a%3c %0a%3c ^7%0a%3c %0a%3c you guessed it, sane values stolen right from solanum's example config, lol%0a%3c %0a%3c ^8%0a%3c %0a%3c solanum's devs say crashing on illegal s2s is "fine" because server links%0a%3c should be only given to trustworthy servers%0a%3c %0a
19 host:1686341279=38.87.162.8
