snomasks, opers, global (remote), ..
For disk logs we currently ignore the sources and log everything.
NOTE: REHASH is untested and will memory leak for sure.
Also rename them to describe better what they do.
ConfigFile:
cf_filename -> filename
cf_next -> next
cf_entries -> items
ConfigEntry:
ce_fileptr -> file
ce_varlinenum -> line_number
ce_fileposstart -> file_position_start
ce_fileposend -> file_position_end
ce_sectlinenum -> section_linenumber
ce_varname -> name
ce_vardata -> value
ce_cond -> conditional_config
ce_entries -> items
ce_next -> next
ce_prevlevel -> parent
Also add doxygen docs for both structs.
Note that without such a block nothing will be sent to ircops at all
(anything that comes from unreal_log anyway).
In a later commit either a snomasks.default.conf will be added and/or
an internal default mapping.
This also moves the recursion trap to earlier in the logging code,
which has the side effect that debug traffic regarding snomasks is
no longer logged.
change some more calls to make_channel() to use find_channel().
Also make it take 1 argument instead of 3.
Needed to be careful in sjoin code since the previous code set
channel->creationtime to 0 if client was a remote. Now merged
a few if's into one. Should be correct :D.
logging. We already did so for the "timestamp" of the log message,
but now also do it in other log messages that have a timestamp,
such as "set_at" and "expire_at" in TKL entries.
This will likely reduce performance, but this should not matter in modern times.
Also added flags to let modules know which one the entry belongs to, and what
to do with it.
Now modules should be able to add their own WATCH methods (like IRCv3 MONITOR),
or extend functionality to notify about other changes than the default log on,
log off and away statuses (like SETNAMEs).
Normally, channel operators are only notified when another chanop
invites someone to their channel - as this would allow the user to
join the channel later if it becomes invite-only. This is still
the default behaviour. But now, it can be configured to notify
operators about any invitation done to their channel, eitner by
another op or by normal user. This will allow them to see whether
someone floods others with invitations to their channels.
Enable the option with set::normal-user-invite-notification yes;
* Converted 90% of the socket and linking errors to use unreal_log()
* Add log_data_socket_error(fd) and $socket_error
* This also makes connect_server() 'void' and removes all of the error
reporting from the callers (there was 3x code duplication due to that)
* Don't use report_error and report_baderror anymore in socket.c
* More to follow...
This adds __attribute__((format(printf,X,Y))) to several functions.
It also adds checking only for the non-literal case to some functions
such as unreal_log/unreal_do_log.
This so we can more easily detect format string issues. Especially now with
the recoding of the logger and with possible future mistakes in this area
in UnrealIRCd 6 itself or in third party modules.
The check is currently disabled in these files, which are TODO items:
* src/send.c: still much work to do
* src/socket.c: due to report_error and report_baderror().
I want to get rid of these functions and integrate them
in the new logger anyway.
* src/serv.c: only disable for hunt_server()
This broke SASL services autodetection and also sasl=x,y,z in CAP.
Reported by Valware in https://bugs.unrealircd.org/view.php?id=5960
Of course the easiest solution would be just to set .remote_write=1
for this, which is what I've just done for the 5.2.1.1 release.
But there seems to be a pattern here. When a server wants to write
its own object (irc1.example.net writing to the MD object of
irc1.example.net) we have the problem that that object is both
"our client" and from the other server POV it is "themselves".
On one hand you may want to allow that (eg for 'saslmechlist'), on
the other hand a server writing its own 'certfp' sounds like a bad
idea in principle.
So we now add a new option for the 'self' case and make some MD
objects use it. In fact, in the core we now have zero MD objects
using remote_write. We keep the option available though, for example
for k4be's geoip modules and possibly future features.
Module API change:
* .self_write added which allows a server to write to its own object
(irc1.example.net writing to the MD object of irc1.example.net)
* .remote_write still exists too if you want to allow remote servers
to write to your own objects
* Note that in all cases, servers can always write to their own
(child) client objects.
Changes:
* The link-security MD changed from .remote_write=1 to .self_write=1
* The salmechslist MD now has .self_write=1, this fixes the actual bug
later fd_close() call. This also removes fd_map() since fd_open w/FDCLOSE_NONE
now does that.
* If you use fd_socket() or fd_accept(), then no change.
When fd_close() is called we call close() on *NIX and closesocket() on Win.
* If you use fd_fileopen(), then no change.
When fd_close() is called we will call close() on both *NIX and Win.
* If you used fd_open() and then fd_unmap() because you didn't want us
to close the socket, then use fd_open() with FDCLOSE_NONE and
just call fd_close() instead of fd_unmap().
We will not actually close the fd in fd_close() (FDCLOSE_NONE).
* If you called fd_open() with other intentions then either specify a
FDCLOSE_SOCKET / FDCLOSE_FILE as the last argument, or more likely:
don't use fd_open() at all and use fd_socket() or fd_fileopen() instead.
For reasons on this change, see previous patch. This way is more sane and
makes it harder to make mistakes even beyond Windows-specific issues.
This fixes a file descriptor leak in Windows that happened in the
logging code. The most visible effect of this was if you had a
log::maxsize set then on Windows you would see:
"Max file size reached, starting new log file"
Every other line, forever (and not actually starting a new log).
fd_close() previously did not close the file descriptor of a file
on Windows because on Windows it needs to call close() for a file
and closesocket() for a socket, and it always did the latter.
On *NIX it's more easy and you can just always close() any fd.
if on OpenSSL 1.1.1 or later.
We trust OpenSSL 1.1.1 and later to be good enough to handle all
the reference counting and freeing nowadays, which is something that
was not done correctly in (much) older OpenSSL versions, leading
to crashes on one hand and on memory leaks on the other hand.
In OpenSSL 1.1.0 and earlier we do not rehash tls on simple "REHASH",
since that code has not been vetted. However, nobody should be
running those old OpenSSL versions anyway, since they are out of
official OpenSSL support.
that only set +r on people. To my knowledge, practically no services are
out there anymore that do not use proper SVIDs (and that can link with
UnrealIRCd 5).
I would like a bit more room for this in the future,
but until then we will keep sending UIDs of length 9 in
server to server traffic, so no change at all.
https://bugs.unrealircd.org/view.php?id=5925
This does two things in cmd_uid() now:
* It checks if parameter 6 in UID is a valid UID, using valid_uid()
* It checks if the first 3 characters of the UID match the SID
Modules can still opt-in via mreq.remote_write=1 to allow it for
certain moddata.
For example, k4be may want to do this for his geoip-base module which
allows a single server to set moddata "geoip" for all connecting clients,
including remote clients.
If you are a moddata provider then you can enable it like this:
ModDataInfo mreq;
[..]
#if UNREAL_VERSION_TIME >= 202125
mreq.remote_write = 1;
#endif
[..]
See discussion on https://github.com/unrealircd/unrealircd/pull/142
This also allows known-users to execute slightly more commands per second.
For people who want their trusted users/bots to allow even more commands
per second (eg 20cmds/sec) we now have a nice FAQ item that uses this:
https://www.unrealircd.org/docs/FAQ#high-command-rate
They were already ignored in MODE by remote UnrealIRCd servers,
but this makes it so local modes (+Z and +d at the moment)
are not sent across the wire.
This also changes the channel_modes() function to have an additional
'hide_local_modes' argument. Set this to 1 if you are building a
buffer that will be sent to remote servers, otherwise use 0,
which is far more common.
Also, this will skip saving of local channel modes to channeldb
since all of these are temporary, or at the moment anyway.
Thanks to alice for reporting this bug and providing a good test
case to help fix this issue and the previous ones.
Bram Matthys