1) Warn when >= July 1, 2022 that we only do security fixes (but continue the report)
2) Error when >= July 1, 2023 that all support ceased (do not send a report)
3) Handle HTTP 403 condition
configuration. It was always cleaning up old entries after 2 minutes.
That is, until the first REHASH happened, after that the correct
connect-flood setting was applied.
In practice, with the default configuration, this means that instead
of 3:60 it was 3:120 until the first REHASH, and after that 3:60.
This was caused by update_throttling_timer_settings() being
called before init_throttling().
from https://curl.se/ca/cacert.pem. Has a few changes, but the most
notable change is that they removed DST Root CA X3. This fixes
verifying Let's Encrypt certificates if you use the "DST Root CA X3"
chain (which is currently the default in certbot and all) on:
* OpenSSL 1.0.2 or earlier (old but in use on eg: Debian 8, Ubuntu 16.04, ..)
* LibreSSL below 3.3.5/3.2.7 (so until a day ago)
This only affects outgoing connections, so for remote includes and
for server linking. Server linking is only affected if you use the
link::verify-certificate option, which most people don't use.
On a side note, ISRG Root X1, so the "real root" for Let's Encrypt is
already included since August 2017 (c8a67f9436)
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
instead of standard wildcard.
In this case, since it's antirandom, it is not really important
as someone is not going to add DNS records specially to avoid
triggering antirandom. That makes no sense since it is much
easier to avoid using a random looking name.
Main reason of changing it here is to set a good example.
arbitrary hosts that have a host starting with "127.". A rather stupid
oversight on my part, really.
In the meantime, if this happens, then you can still resort to using
ZLINE/GZLINE as a workaround to ban such a user. (The exemption won't
match against the host because DNS lookups are not done for zlines)
Reported by armyn in https://bugs.unrealircd.org/view.php?id=5957
This was more of a oversight because the cmdbytes calculation happens
in a different function after message tags have already been processed.
Also, wasn't really important up to now since we only allow quite short
tags at the moment.
Instead of just counting these in cmdbytes, as would be the most logical
and easiest fix, we use a different strategy:
We use a separate counter for message-tags so clients benefit from the
"rounding down rule". In other words: the first xyz bytes give you
no extra penalty compared to before (eg they are "free"). Useful for
clients who use eg @label heavily.
By default this is 90 bytes for unknown-users and 180 bytes for
known-users. See lag-penalty-bytes in set::anti-flood.
(often completely unrelated to channel history) and you then rehashed again
UnrealIRCd would crash. Reported by gh0st.
May be the same issue as reported by adamus1red in
https://bugs.unrealircd.org/view.php?id=5943
This has to do with SavePersistentPointer/LoadPersistentPointer calls
which normally work fine but this particular module uses it in MOD_TEST
causing a certain sequence of events causing a double free or read-
after-free if you do it slightly differently.
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.
Based on previous reports and patches from k4be in
https://github.com/unrealircd/unrealircd/pull/129
Looks much cleaner now.
This also filters out the edge case where user_account_login()
could have been called when a user transitioned from "not logged in"
to "unconfirmed account". It did not cause any issues AFAICT but
it is not really expected either.
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).
services account.
This adds set::authentication-prompt::unconfirmed-message with
a default of:
unconfirmed-message "You are trying to use an unconfirmed services account.";
unconfirmed-message "This services account can only be used after it has been activated/confirmed.";
See https://www.unrealircd.org/docs/Set_block#set::authentication-prompt
Note that this is only shown for services which allow SASL from
unconfirmed services account in the first place, like atheme.
Anope does not allow it, which is something that could very well
be considered 'correct' as well. In that case you would simply
get the "Authentication failed" message instead
(set::authentication-prompt::fail-message).
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
* New block [set::server-linking](https://www.unrealircd.org/docs/Set_block#set::server-linking)
* For link blocks with autoconnect we now default to the strategy
'sequential', meaning we will try the 1st link block first,
then the 2nd, then the 3rd, then the 1st again, etc.
* We now have different and lower timeouts for the connect and
the handshake. So we give up a bit more early on servers that
are currently down or extremely lagged.
set {
server-linking {
autoconnect-strategy parallel;
connect-timeout 10s;
handshake-timeout 20s;
}
}
Right now the only autoconnect-strategy is 'parallel', which is simply
the existing behavior since 4.x. A future commit will add other
strategies and may or may not change the default as well.
The bit that is working already is that you can now specify different
timeouts for the connect()/TLS_connect() call and for the rest of
the handshake (when the "SERVER" message is seen), this so the connect
timeout can be relatively short.
All this will be documented later in the wiki and release notes.
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.
~a:0: match all unauthenticated users
~a:*: match all authenticated users
~a:SomeUser: match only SomeUser, also allow wildcards here, even
though that is usually a very bad idea :D
- If you have only negating entries, like '!abc' and '!def', then
we assume an implicit * rule first, since that is clearly what
the user wants.
- If you have a mix, like '*.com', '!irc1*', '!irc2*', then the
implicit * is dropped and we assume you only want to match *.com,
with the exception of irc1*.com and irc2*.com.
- If you only have normal entries without ! then things are
as they always are.
This patch also makes the behavior for unreal_mask_match() and
unreal_mask_match_string() the same.
If you had a spamfilter on type 'c' but not on 'p' then it would not
trigger. Reported by armyn in https://bugs.unrealircd.org/view.php?id=5913
This probably went unnoticed because most people add spamfilters
on 'pc' (or even 'pcnN').
Reported by Ariadne Conill in https://bugs.unrealircd.org/view.php?id=5906
This patch applies cleanly against 5.2.0-rc1 and 5.0.9.x.
Needs more testing, though, as fiddling with SQUIT code and the
various directions and far/near server distinctions can be tricky.
of an error. Also the warning will differ depending on whether you use
the defaults that were in example.conf for a long time, or some custom
settings.
It's not perfect but should help people with migrating from 5.0.x to 5.2.x.
Replace it with a reference to the documentation instead of trying
to include some or all of the defaults since 1) the block is huge
nowadays with all the settings, and 2) this way we can tweak the
defaults over time in newer versions rather than having people
change their configuration file.
Suggested by westor in https://bugs.unrealircd.org/view.php?id=5838
This also fixes a bug where output from modules for 'STATS S' was
shown twice (eg: modef-default-unsettime shown twice).
for "unknown-users" and "known-users".
As a reminder, by default, "known-users" are users who are identified
to services OR are on an IP that has been connected for over 2 hours
in the past X days.
See https://www.unrealircd.org/docs/FAQ#new-anti-flood-block
for more information on the layout of the new block.
NOTE: This actual feature, the relase notes and the documentation
are all work in progress.
I think people will understand both and it is currently rather long.
And a bit confusing too with all the spaces, easy to overlook something eg
in /STATS S where it is being used.
See https://ircv3.net/specs/client-tags/reply for the draft.
Can be used by clients to indicate to which message they are writing
a reply. This can be especially useful for bots, to indicate that
a response belongs to a user request, eg a !trigger.
The new target type is called 'T' and we match against "name=value"
of each message tag (or just "name" if it is without value).
Example: SPAMFILTER ADD -simple T kill 0 this_is_a_test +typing=active
(No this is not a suggestion :D)
This probably won't be used much at all, but it is good to have the
option available in case there is some massive problem,
especially since more message tags may pop up sooner or later.
Caveat: this is actually a bit slow as we may have to check multiple
message tags for a single line.
If there are zero message-tag spamfilters then we will automatically
short-circuit and save all this CPU, which will be the most common case.
in case you want to disable this feature.
Note that clients that are using CHATHISTORY will already no longer
receive history-on-join ("push") since they REQ a CAP that will inhibit
this and they will "pull" the history instead when they want/need to.
So... this option is really only there if you want to disable it for
non-CHATHISTORY-clients.
loaded. The code to raise this warning was already present but it
was not being shown in many cases (when it actually should).
It now looks like this, if you run ./unrealircd start and previously
crashed AND have any 3rd party mods loaded:
The IRCd has been started now (and is running), but it did crash 1 seconds ago.
Crash report generated in: /home/ircd/unrealircd/tmp/crash.report.core.1621838267.txt
** IMPORTANT **
Your UnrealIRCd crashed and you have 3rd party modules loaded (modules created
by someone other than the UnrealIRCd team). If you installed new 3rd party
module(s) in the past few weeks we suggest to unload these modules and see if
the crash issue dissapears. If so, that module is probably to blame.
If you keep crashing without any 3rd party modules loaded then please do report
it to the UnrealIRCd team.
The reason we ask you to do this is because MORE THAN 95% OF ALL CRASH ISSUES
ARE CAUSED BY 3RD PARTY MODULES and not by an UnrealIRCd bug.
Shall I send a crash report to the UnrealIRCd developers?
NOTE: If the crash is caused by a 3rd party module then UnrealIRCd devs can't fix that.
is now 5000 lines / 31 days. For unregistered it is 200 lines / 31 days.
Previous setting was 200 lines / 7 days for both.
Admins can tweak these settings, see:
https://www.unrealircd.org/docs/Set_block#set::history
More code to deal with corner issues will follow later.
UnrealIRCd module coders [!]:
This also changes the channel mode API conv_param. You can use
the UNREAL_VERSION_TIME >= 202120 condition to detect this.
Eg:
#if UNREAL_VERSION_TIME < 202120
int my_conv_param(char *para, Client *client);
#else
int my_conv_param(char *para, Client *client, Channel *channel);
#endif
possible if it rounds off nicely, eg +H 100:7d. Note that the
existing syntax is still accepted, eg +H 20:1440 and +H 20:1440m
are both converted to 20:1d.
With potentially higher time values this change makes the mode
parameter a lot more readable.
Support for translating timevalues is already in UnrealIRCd 5.0.2
and higher, so should be fine for nearly everyone.
from https://ircv3.net/specs/extensions/chathistory
Current status of the module in UnrealIRCd:
* A significant part of this is done and working
* Currently in modules.optional.conf to get test exposure,
not yet loaded by default.
* CHATHISTORY subcommands implemented: BEFORE, AFTER, LATEST, AROUND
* It does not implement the subcommand "BETWEEN" yet
* It does not announce or recognize the (draft) CAP's yet
* It does not announce the ISUPPORT token CHATHISTORY=xx yet
* Testcases need to be written to validate everything
* There will be bugs, now, and also while implementing the rest
in the days to come.
the file is allowed to no longer exist. This so you can do things
like only connecting an USB stick during UnrealIRCd boot and then
pull it out once booted.
* Fix channel history issues with writing on terminate
* Change tkldb and reputation to only write the db
on terminate and not on every REHASH anymore
..all this thanks to the new loop.ircd_terminating, so modules can
see the difference between regular rehash and terminating.
so modules can indicate if they wish to be unloaded before or after others.
This is used by the channel and history modules so they can save their
databases before the chanmodes modules are unloaded.
Also, made ModuleSetOptions() a void function. I don't think anyone
used the returned value and it now no longer is strictly bitmask add/del
so returning an unsigned int would be a tad confusing.
we may have more database writing to do on terminate.
Actually 10 seconds would be really long, but 2-3 seconds may be
quite realistic if you have lots of TKLs, permanent channels,
reputation entries (users), etc.
Oh yeah, and I really hate writing PORTABLE shell code...
configuration on how history is stored (in memory and/or on disk).
This is similar to other disclosing policies like
unrealircd.org/link-security and unrealircd.org/plaintext-policy.
The reason for this cap (and similarly the other caps) is that
the user can make an informed decision on whether it finds the
policy/safety/privacy of an acceptable level or not.
Fixes for turning persist on/off on the fly (REHASH)
Make release notes a bit more clear.
on what hardware people end up running UnrealIRCd.
Also (unrelated) add a check for >64kb strings in unrealdb_write_str()
and return an API error. That too is unlikely to ever happen, but..
better be correct.
src/unrealdb.c(462): error C2220: warning treated as error - no 'object' file generated
src\unrealdb.c(379) : warning C6029: Possible buffer overrun in call to 'fread': use of unchecked value 'c'.
[..fread of c->config->saltlen..]
if (c->config->saltlen > 1024)
{
unrealdb_set_error(c, UNREALDB_ERROR_HEADER, "Header is corrupt (saltlen=%d)", (int)c->config->saltlen);
goto unrealdb_open_fail; /* Something must be wrong, this makes no sense. */
}
c->config->salt = safe_alloc(c->config->saltlen);
if (fread(c->config->salt, 1, c->config->saltlen, c->fd) != c->config->saltlen)
VS2019 doesn't understand that this is safe.
And set the error message/code properly. Didn't set it before because of
'c' being freed, but we have unrealdb_get_error_code() and
unrealdb_get_error_string() now that can (and should) still be used
in such cases.
not always kicking in on *line either.
We now check for shuns/*lines in user_account_login(), so upon
SASL or NS IDENTIFY etc. This also means that the client could
now be killed in that function, so callers should take extra
care and take that into account. We check for IsDead() in our
calls now (if it's our client anyway).
Hopefully this doesn't break anything.........
I forgot to include message tags earlier, so this is a breaking change:
-int hooktype_local_nickchange(Client *client, char *newnick);
-int hooktype_remote_nickchange(Client *client, char *newnick);
+int hooktype_local_nickchange(Client *client, MessageTag *mtags, char *newnick);
+int hooktype_remote_nickchange(Client *client, MessageTag *mtags, char *newnick);
Be sure to update your hooks!
You can use something like: #if UNREAL_VERSION_TIME>=202115
This library provides easy to use functions for encryption/decryption
among other things. There is some overlap with things that
OpenSSL also provides but not all.
The new display field is called 'R', use something like:
WHO * %cuhsnfmdaRr
At the moment only "displaying" is available and not "searching"
on reputation. If you need that, you're stuck with the /REPUTATION
command at the moment. Too much hassle to implement that.
About reputation: https://www.unrealircd.org/docs/Reputation_score
Note: the only change between 5.0.9 and 5.0.9.1 is:
* Build improvements on *NIX (faster compiling and lower memory requirements)
* Windows version is unchanged and still 5.0.9
Type: Parallel build: Non-parallel build:
Before change 92 seconds 304 seconds
After change 7 seconds 21 seconds
All this thanks to a simple --disable-tests being passed to c-ares' configure.
(that is, MemAvailable, not MemFree). The ./Config script with
all shipped libs compiled actually has a memory peak of 450M
in my tests with -j4, but let's err on the safe side...
Reason for all this:
This helps on shells with limited memory, especially if they
don't have swap.
We actually don't take swapping into account, so even if you
have plenty of swap but "low" on memory then we won't force a
parallel build. That's okay, since in such a case a parallel
build is not so useful anyway with (slow!) swapping.
This code only works on Linux. Let's hope *BSD guys are smart
enough to have a decent system setup.
need this and it slows things down for servers.
For clients it's not much of an issue, since traffic rates are low.
However, for server-to-server links it is an entirely different matter.
It is (only) noticeable if you have lots of traffic, such as when there
is a lot to sync while linking two servers, and especially when the two
servers are geographically further apart.
Tested with 100,000 G-lines on both sides being synced (20MB traffic):
* 20ms RTT (same country/state): speed up of x3
* 200ms RTT (transpacific): speed up of x6
We moved from LibreSSL 3.1.4 to 3.2.4.
Support for TLSv1.3 was added in LibreSSL 3.2.2 from Oct 2020,
but it had some issues, hopefully by now they are resolved.
[skip ci]
Suggested by Amiga600 in https://bugs.unrealircd.org/view.php?id=5784
This also fixes a bug with log::maxsize on Windows (cannot overwrite
existing file with .old).
It simplifies the logging code a little and makes it a tad more readable.
And it adds an unreal_strftime() function to make things easy.
the spamfilter. Only after a rehash it showed the me::name as the
setter. From now on we just display -config- in the setter field,
like we do for all the other TKLs as well (ELINE, ban xyz, etc).
if running multiple ircds from the same directory you sometimes get
weird messages otherwise (not that we really support such a thing
but i use it while dev'ing).
Not reported by anyone, but yeah.. who knows there is someone out there
that does this :D.
Also make it work the same like channeldb by spreading the event.
If a module returns 0 ("UnrealIRCd please do not process this packet")
then don't call the next module in line (also because that one might
then change the return value to something different, which is bad).
That is, when in "auto" mode, which is like for 99% of the users.
NOTE: the sytem may still limit the actual number of FD's to
a lower value, depending on the value of "ulimit -n -H".
notices to IRCOps and in ircd.log.
See the release notes for more details.
Module coders:
You can use HOOKTYPE_CONNECT_EXTINFO to add your own additional
information as well. See get_connect_extinfo() for inspiration.
Use nvplist_add() or nvplist_add_fmt() to easily add your info
to the list.
Module coders II:
Small note: this moves the sending of the far connect notice
to /under/ HOOKTYPE_REMOTE_CONNECT instead of /above/.
When booting no log files are open yet as we have not parsed any log { }
entries yet. On *NIX we log to stderr during that stage.
On Windows it varies: when running in GUI mode we save the log to a
buffer and display it after booting in a dialog.
When running as a service on Windows we previously wrote SOME entries
to service.log, but other entries were not logged or shown anywhere.
This makes both GUI and Service-mode on windows log all ircd_log()
calls with LOG_ERROR, instead of only config_status(), config_warn()
and config_error() messages.
This also removes config_progress() which isn't used by anything.
Oh, and it also fixes a memory leak in the Windows boot code, a leak
that nobody would have noticed anyway, but still.
The handshake delay exists so results from DNSBL's can be checked before
the user is fully online. Whenever someone is exempt from DNSBL checking
it serves no purpose, so we mark it that the user has no handshake delay.
This will speed up connecting by up to 2 seconds (by default).
Also updated WebIRC example to suggest this now:
https://www.unrealircd.org/docs/WebIRC_block#UnrealIRCd-side
The exempted ban types are only ones that will affect other connections as well,
such as gline, and/but not policy decissions such as bypassing qlines or maxperip.
Currently the list is: gline, kline, gzline, zline, shun, blacklist,
connect-flood, unknown-data-flood.
Suggested by PeGaSuS and others in https://bugs.unrealircd.org/view.php?id=5806
And if it is actually used/installed then make it a little bit
harder to bypass the case where the digitale signature does not match.
And yes, the bypass option does exist because in the future we
may have a different signing key. Who knows from what old version
people may upgrade years from now, after all.
Previously it rejected ! for all type of *LINES to avoid users
making the mistake of banning nick!user@host in a *LINE.
Note that for non-extended-server-bans the ! is still forbidden.
* There are two security groups by default: known-users and unknown-users.
See https://www.unrealircd.org/docs/Security-group_block
* New extended ban ~G:securitygroupname, with the typical usage being
MODE #chan +b ~G:unknown-users, which will ban all users from the
channel that are not identified to services and have a reputation
score below 25.
It is highly recommended that services pseudo users all have +o since
there are likely many places where ULines don't bypass a restriction while
opers do. But still, this particular issue has been fixed, it caused
unexplained loss of messages which looked rather mysterious.
Reported by severinmueller in https://bugs.unrealircd.org/view.php?id=5799
The reputation command (IRCOp-only) has been extended to make it
easier to look for potential troublemakers:
* ```REPUTATION Nick``` shows reputation about the nick name
* ```REPUTATION IP``` shows reputation about the IP address
* ```REPUTATION #channel``` lists users in channel with their reputation score
* ```REPUTATION <NN``` lists users with reputation scores below value NN
to the specified number of lines. This defaults to 1000.
This will prevent IRCOps from being flooded off ("Max SendQ exceeded")
if they list all *LINES and there are thousands.
In the newly introduced error message, after too many matches,
we also kindly point out to use filters like '/STATS gline +m *.nl'
When packaging UnrealIRCd as RPM, 'make install' needs to install
the files into $RPM_BUILD_ROOT rather into '/'. Just changing the
paths via ./Config or ./configure does not fit, because otherwise
UnrealIRCd is finally looking for $RPM_BUILD_ROOT/etc/unrealircd/
rather /etc/unrealircd/. It's fully backwards-compatible, because
normally $DESTDIR is not being passed.
Thank you BuildBot.
This means on older OpenSSL's we are not going to have certificate
expiry checks. Those OpenSSL versions were deprecated by the OpenSSL
team itself, so yeah then you will miss out a few things.
by armyn in https://bugs.unrealircd.org/view.php?id=5769.
The default behavior in 5.x is to continue matching:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*; password "iwantmore"; class clients; maxperip 10; }
This so users who provide a password get additional rights,
such as a higher maxperip or a different class, etc.
If the user connects without a password then we simply continue
to the next block and use the general block with only 2 maxperip.
However, some people want to use passwords to keep other users out.
That is entirely understandable as it is an 'allow block' after all.
For example:
allow { ip *@*; class clients; maxperip 2; }
allow { ip *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }
In this case anyone without the correct password will be rejected access.
if someone searches explicitly on a nick name and that user exists.
This fixes a bug where doing '/who name a' would return only 1 result
if 'name' exists as a nick, even though multiple people with the
same account 'name' are online and visible to the user, as
reported in https://bugs.unrealircd.org/view.php?id=5761 by Koragg.
Reported by Adanaran in https://bugs.unrealircd.org/view.php?id=5698
Although voiced users normally bypass bans, it is not really logical
for them to bypass filtering of banned words, since that is normally
a policy decission by channel management. So +v will not bypass it.
1) The problem is that this is enforced at the ban layer API. The extban
routines, textban in this case, are not called when the user is voiced,
because voiced users bypass bans. If we would change that in the ban API
then voiced users can also no longer talk through (=bypass) regular +b or
other extended +b such as ~a (account) etc.
2) I figured we would then make +T not use the ban API but the
can_send_to_channel hook instead. However, then you have to do manual
looping through bans and such, it's rather ugly from a coding point of view,
and you risk "missing" things like ~T stacked with ~t.
3) Then I went back to look if the ban API could be changed by having the
textban module set a flag and then the ban api would call that specific
module still for voiced users. While starting on that, unfortunately things
(variables, arguments) cascaded quickly into having to change all kinds of
underlying functions that would break the module API.
4) I then went back to option 2 and implemented it, trying to deal
with all its caveats.
reported by Koragg in https://bugs.unrealircd.org/view.php?id=5757.
This changes the following in the code of who_global():
1) We initialize all the 'marked' users to zero at the beginning,
and remove the previously unmarking in the bottom loop that
shouldn't have anything to do with it. Now there's "no way"
to screw up initialization of marked users.
2) Check for marked users in the bottom loop.
3) Thanks to #1 and #2 we can now easily add simple logic like
not skipping when client==acptr.
4) Similarly, we can remove checks for +i/-i in who_common_channel(),
and as a bonus we will list common channel results altogether
in the WHO result, rather than first +i on common and then at the
very end the remaining -i (which may also be in common channels).
All in all, the code is now more like how I would write it, rather
than the original. It's now harder to screw things up if you change
some visibility or searching logic here or there.
That option specified a Diffie Hellman parameter file. Since
UnrealIRCd 5.0.0 we no longer process this option.
This option has never been documented in the wiki docs.
We prefer and use ECDHE/EECDH with SSL_OP_SINGLE_ECDH_USE since 2015
to provide Forward Secrecy in SSL/TLS. And indeed, by now in 2020,
any properly maintained software uses it and old DH(E) usage has
fallen to less than 1%.
What this patch does is remove the unused code (since Dec 2019) and
show a warning if you have a ::dh config directive, so that at least
you are informed that it is unused/ignored. Since it was undocumented
it probably hardly affects anyone, but still, it is proper to inform.
numbers only. This makes things more logical for end-users.
This fixes https://bugs.unrealircd.org/view.php?id=5746,
bug reported by KindOne.
The same issue was also fixed by previous commit, but still:
it is better to limit things to a narrower range, this so you
don't get different behavior depending on the CPU a server uses.
This adds support for latvian-utf8, estonian-utf8 and lithuanian-utf8
in set::allowed-nickchars. Patch from moseslecce.
Co-authored-by: David Lecce <3292014+davidlecce@users.noreply.github.com>
This should be rare, since modes-on-connect is in the example
configuration file with +ixw since 2003, but still... just in
case someone completely misses the modes-on-connect configuration
item, then make sure that we have a safe and good default.
set::history::channel::playback-on-join::lines and
set::history::channel::playback-on-join::time were ignored,
the limit in the +H channel mode was used instead.
Reported by k4be in https://bugs.unrealircd.org/view.php?id=5707
happens if all of the following are true:
1) You use link::outgoing::tls-options (or ssl-options)
2) You do a REHASH -tls (or REHASH -ssl)
3) You do NOT do a regular REHASH
4) You try to link to the server in such a link block (outgoing!)
In other words: the problem may happen if you try to link after
a Let's Encrypt cert renewal, unless there has been a regular
REHASH between that and the outgoing linking attempt.
Reported by k4be and Le_Coyoto in https://bugs.unrealircd.org/view.php?id=5607
depending on the module load order. Reported by k4be.
Changes:
* Websocket hooks:
* Input should be run first
* Output should be run last
* Labeled-response also had various hook priorities wrong
* Pre command should be run near-first
* Post command should be run near-last
* Close connection (does the flush) should be run near-last
* Packet should be run near-last
Previously it didn't display correctly on server notice the TLSv* version on local connection.
Before: TLS_CHACHA20_POLY1305_SHA256
After: TLSv1.3-TLS_CHACHA20_POLY1305_SHA256
set {
anti-flood {
target-flood {
channel-privmsg 45:5;
channel-notice 15:5;
channel-tagmsg 15:5;
private-privmsg 30:5;
private-notice 10:5;
private-tagmsg 10:5;
};
};
};
Max 45 messages in 5 seconds means max 540 messages per minute,
with a peak of (surprise) 45 messages per 5 seconds...
That should be sufficient for every legit channel, right?
How can you chat if you get more than 9msgs/sec for 5 seconds straight?
Maybe I am even too liberal with these limits?
NOTICE and TAGMSG get lower limits because they are far less used
and have other concerns (eg: ringing a bell for NOTICE).
The default limits may be changed in later versions of UnrealIRCd
based on feedback and more insight in (big) channel rates.
This provides ROP hardening, which is actually quite nice.
However, it requires CPU hardware support, which is pretty
non existant at the moment. So, right now, on most systems
this option will do nothing.
This is 1,5 years after 459a55245a
and we're on a new series too (5.0), so it was about time.
And YES you may still use }; if you want to. There are no
plans to deprecate or warn about it.
We simply ship with } in the shipped configs because it is
more logical that both { and } don't require a ; rather
than only { not requiring it.
Also, remove unnecessary comment about calling lr_post_command() with
the last two arguments being NULL. We don't use these two variables
inside lr_post_command() after this change anyway.
Then the oper may decide if the original entry should indeed be
removed and re-added, or if (s)he should not touch it. These are
usually done by mistake anyway.
Updating existing entries by end-users was never intended and did
not work properly anyway (see bug comments). Issue reported by
Le_Coyote and armyn in https://bugs.unrealircd.org/view.php?id=5603
This had to do with the queued packet (in the labeled-response module)
not being sent because the client was freed before the
post packet hook was called.
any parameter channel mode module loaded after channeldb.
Reported by GaMbiTo, with help from PeGaSuS, Gottem and k4be
in https://bugs.unrealircd.org/view.php?id=5669
It is not safe to call channel mode parameter functions when
unloading modules. Makes sense I think.
We now no longer write the db on rehash, which is something i
didn't like anyway (wasted CPU cycles). The problem was that
one could not just scratch the write db call, as otherwise if
someone rehashes every minute would cause the db never to
be saved. This is because on each rehash the event to write
the db gets rescheduled to +5 minutes in the future.
We now work around that in the same way as connthrottle does.
Obviously it would be better to make the event system itself
deal with this, but that is (way) too much for now.
This was a FIXME item that should have been addressed earlier.
We didn't use any MODDATATYPE_CHANNEL in the core up to now so
this was overlooked. We do use it from now on, though, and it
may very well have been used in 3rd party modules already.
This is the work from May 3rd.. need to commit it so i can merge the
flood protection that is related to this...
The final implementation will still need tweaking before pushed.
[skip ci]
no connect-delay restriction. Also remove the 'disable' option since
it is unneeded. You now simply use:
set {
restrict-commands {
somecommand {
}
}
}
...and the command is disabled.
And you add exempt-identified or exempt-reputation-score if needed.
See https://www.unrealircd.org/docs/Set_block#set%3A%3Arestrict-commands
Note that this also changes some command blocking logic, so I hope
I made no mistake there... only testing will tell.
version or newer on the sytem, otherwise we fall back to shipped version.
This fixes https://bugs.unrealircd.org/view.php?id=5187 among others.
It means:
* Case insensitive matches work better in UTF8 now, such as extended Latin.
For example, a spamfilter on "ę" now also matches "Ę", while previously
it did not catch this.
* Other PCRE2 features such as https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC5
are now available. For example you can now set a spamfilter with the regex
\p{Arabic} to block all Arabic script, or
\p{Cyrillic} to block all Cyrillic script (such as Russian)
Use these new tools with care, of course. Blocking an entire language,
or script, is quite a drastic measure.
All of this was possible because of the new PCRE2_MATCH_INVALID_UTF
compile time option which was introduced in PCRE2 10.34.
This also means we now require at least that PCRE2 version so
everyone can benefit from this new spamfilter UTF8 feature.
Many systems come with older PCRE2 versions so this means we will
fall back to the shipped PCRE2 version in UnrealIRCd. This means
./Config will take a little longer to compile things.
Although there is no indication as of now, but if this feature would
break things heavily then it might get reverted or configurable.
This is also why it was added just after 5.0.4 release and not right
before it, it needs some heavy testing.
Reported by k4be and others.
For the crash to occur a few specific things had to happen:
1) The system is missing the argon2 dev library (or it is too old)
causing us to use the UnrealIRCd-shipped argon2 library.
2) You ran ./Config while there is an existing IRCd running
3) Now some argon2 hash is being checked (eg due to an OPER attempt)
4) Crash
A very similar crash happens (to a LOT more people) when you
run './unrealircd restart' to do the actual upgrade. In such
a case, the old IRCd crashed (the one that was actually supposed
to die anyway). The annoying thing was that the crash reporter
would kick in to report such a crash which was actually quite
harmless. This is actually the same crash as described earlier
so should be fixed as well now.
This variant was reported by Shillos and others.
TLSv1.0 or TLSv1.1. Otherwise it is impossible to enable by the application.
We are still going to turn off TLSv1.0 and TLSv1.1 by the end of this year
by default. Ubuntu 20.04 is just a couple of months too early. See also
the various browsers who postponed disabling TLSv1.0/TLSv1.1.
Also, regardless of the above, we want the admins running the IRC server
be able to control this and not having such a breaking change be dependant
on some distro default settings.
This results in a more general error message that is easy to google.
Also fix the gmake error to complain about make/gmake since it
may also indicate missing make.
We will extend the option later in UnrealIRCd 5.0.5.
This purely has to do with keeping the changes for 5.0.4 small and
contained since that will be mostly a bug fix release.
Since 5.0.5 will have more configurable options for hide-idle-time, I
have already renamed the single option that is exposed in 5.0.4
to set::hide-idle-time::policy since set::hide-idle-time is a
configuration block now, see docs at:
https://www.unrealircd.org/docs/Set_block#set%3A%3Ahide-idle-time
When connecting, use slightly different wording (and use it consistently):
"Trying to activate link with server xyz"
When the connection is lost before synced:
"Unable to link with server xyz"
When the connection is lost after fully synced (eg: minutes later):
"Lost server link to xyz"
Important small changes (other than text):
* Log ERRORs from remote servers to the log (previously only shown to ircops)
* Some link errors could have been previously suppressed due to
old code assuming other parts of the code would send or log the error
(this would be the case for an error when calling SSL/TLS write functions)
* More?
I think nowadays, with more attention to privacy, we should make this
option settable by users.
See previous commit for more information, or just visit the doc page at
https://www.unrealircd.org/docs/Set_block#set%3A%3Ahide-idle-time
if you want to use a different setting.
connected users for technical reasons, so you will have to use double
whois to see it for remotes (/WHOIS Nick Nick) just like with idle time.
Suggested in https://bugs.unrealircd.org/view.php?id=5519
set::ident::connect-timeout for the read timeout also.
This could lead to failed ident lookups on higher latency connections
because it only gave 3 seconds for the entire ident lookup rather than
the (max) 10 seconds that was intended.
Now both values are properly obeyed (3 for connect, 7 for read
timeouts, by default).
This only happens in some circumstances.
From now on EventDel() will simply mark the event as deleted.
The actual freeing is started in DoEvents() after the event loop.
This makes it safe to use EventDel() everywhere.
The previous attempt to fix that issue was
d29a55a8db but it introduced a
new crash issue for a slightly different case, as mentioned in
https://bugs.unrealircd.org/view.php?id=5553
when used on a multi-server network. This was due to the PART event
inadvertently not being sent towards the SAJOIN direction.
Bug reported by Cheiron in https://bugs.unrealircd.org/view.php?id=5616
form an insecure connection. There we explain a bit on the why and how to
configure some random IRC clients.
This also silently adds support for multi-line messages in
set::plaintext-policy::user-message (for warn) and
set::plaintext-policy::oper-message (for warn and deny).
Eg with anope with the KILL option turned ON, a minute after taking
a registered a nick.
Very similar to c9b88343e2 which was
fixed in 5.0.0-beta1 for non-forced nick changes.
files that end in .core, while on many systems it is just 'core'
without the dot. Reverted back to U4-style core file finding now.
Thanks to DeviL for helping to trace this issue.
off not using this and you'll want to use the three other hooks anyway:
* HOOKTYPE_LOCAL_QUIT - for local quits of registered clients
* HOOKTYPE_REMOTE_QUIT - for remote quits of registered clients
* HOOKTYPE_UNKUSER_QUIT - for local quits of unregistered clients
(that is, before they have completed NICK+USER etc)
and HOOKTYPE_REMOTE_CHANMODE are called from the SJOIN code.
We now set the samode argument to -1 if it is an SJOIN server sync,
so chanmodes/permanent won't destroy the channel while processing
the SJOIN. The SJOIN code already takes care of destroying at the end.
so they can fetch more history than the standard on-join history.
In the future we are also likely to implement IRCv3 CHATHISTORY
once that becomes an official specification. However, until it is
specified and until most major clients support it, several years
are likely to pass. It would be a shame to withhold channel
history to many end-users in the meantime when it takes so little
effort from us to provide an easy command.
See also
https://www.unrealircd.org/docs/Channel_history
And in particular the new section:
https://www.unrealircd.org/docs/Channel_history#Playback_frontends
which explains the relationship between on-join playback,
HISTORY and CHATHISTORY.
This does NOT "fix" https://bugs.unrealircd.org/view.php?id=5538:
WHOIS nick
:localserver.example.com 311 test nick ident host * :realname
WHOIS nick nick
:remoteserver.example.com 311 test nick ident host * realname
.. because your IRC protocol parser should not care about a :
or a lack of :. For text not containing spaces nor :-prefix there
is no difference in meaning and it should parse to the same.
However, this DOES fix an issue if the realname itself started
with a colon, such as "USER x x x ::something":
WHOIS nick
:localserver.example.com 311 test nick ident host * ::something
WHOIS nick nick
:remoteserver.example.com 311 test nick ident host * :something
.. because that does not have the same meaning and is a real
incorrect drop of a character.
Yeah, I took into account spaces, but not a word starting with :, my bad.
Release notes:
+* [Channel history](https://www.unrealircd.org/docs/Channel_history) used
+incorrect time internally, resulting in messages expiring too soon.
+The syntax is now really ```/MODE #chan +H lines:time-in-minutes```.
+To make clear that the time is in minutes, an 'm' will be added
+automatically by the server (eg ```+H 15:1440m```).
Bug reported by k4be.
set::oper-auto-join or tld::channel was broken. It worked for the
very first user since boot or rehash, but after that only the
first channel was joined. Reported by PeGaSuS in
https://bugs.unrealircd.org/view.php?id=5535
useful in the future. This would download a specific patch from
the unrealircd.org site, apply it, recompile, and then:
if it's a hot-patch it would rehash
if it's a cold-patch it would print a message that you should restart
the irc server.
spamfilter (F, not f) and qline (Q, not q).
2) Error out when invalid ban exception types are given, so such errors
don't go undetected anymore. Eg it will now print:
"ERROR: bantype 'f' is unrecognized (in 'fgkz'). Note that the bantypes are case sensitive. Type /ELINE to see a list of all possible bantypes."
Reported by westor and Mi_01 in https://bugs.unrealircd.org/view.php?id=5528
Also, when at it:
3) Remove type 't' from ELINE syntax docs, which is in fact 'c'
(which is already present in the list)
Remove old option set::ban-include-username and replace it with a more
generic option which defines what target a ban should apply to.
Also add some parts of set::manual-ban-target which will follow soon.
Although not entirely true, exempting a user from 'd' when using
an extended server ban or IP or ident is not recommended.
The information needed to exempt the user may not be available
at the time of the flood. Better to reject it than have it partially work.
See https://www.unrealircd.org/docs/Extended_server_bans
Examples with ELINE:
/ELINE ~a:TrustedAccount kg 0 This user can bypass kline/gline when using SASL
/ELINE ~S:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef kgf 0 Trusted user with this certificate fingerprint
It also works with bans, although this would be less common:
/GLINE ~a:EvilAccount
A more useful purpose would be to use ~r (realname):
/GLINE ~r:*some*stupid*real*name*
(Although you could already ban realnames via spamfilter 'u')
For third party module coders:
If you have an extban in group 3 (a "matcher"-extban) then you
can opt-in to support this. You do so at extban registration time:
req.options = EXTBOPT_TKL;
or, if you already had another flag set, like for +I, then:
req.options = EXTBOPT_INVEX|EXTBOPT_TKL;
In any case, you set the .options before you call ExtbanAdd().
Note that if you do indicate support then your is_ok function
will be called like:
extban->is_ok(client, NULL, mask, EXBCHK_PARAM, MODE_ADD, EXBTYPE_TKL);
Important here is the NULL channel (since there is none)
Similarly your is_banned function will be called with BANCHK_CONNECT:
extban->is_banned(client, NULL, banstr, BANCHK_JOIN, &msg, &errmsg);
Here too, it is important to note that channel is NULL.
Add new config option "exempt-webirc yes;" in set::restrict-commands::<commandname> in order to give exceptions in all WEBIRC user. This closes one of the 3 suggestions in https://bugs.unrealircd.org/view.php?id=5506
1) Fix issue if HOOKTYPE_IS_HANDSHAKE_FINISHED rejects the user
2) Fix authprompt issue. We now allow adding the TKL in
place_ban_host() for soft-kline/etc. Previously all the
soft-kline/gline/zline/gzline acted like soft-kill.
3) The blacklist module did not allow clients in with action 'warn',
reported by westor in https://bugs.unrealircd.org/view.php?id=5501
In the configuration item you can now achieve the same via:
except ban { mask 1.2.3.4; type maxperip; }
Or even:
except ban { mask { 1.2.3.4; 8.8.8.8; }; type maxperip; }
etc.
Suggested by The_Myth in https://bugs.unrealircd.org/view.php?id=5507
Also, fixed an issue where the IRCd was counting servers as
clients for maxperip, which doesn't make much sense in practice,
so it only counts users now.
MLOCK restrictions when services are down (set::services-server).
Suggested by westor in https://bugs.unrealircd.org/view.php?id=5273
By default all opers with the *-with-override privilege have this,
which sounds OK to me.
just like hooks now. Yeah we've messed up a few times by now.
Seems only Gottem uses them :D
So now it would call for example: prio -10, prio 0, 10, 20, cmd.
This matches the behavior of hook priorities (and swhois etc.)
Turning these errors into warnings instead should be fine and makes
the upgrade process (and instructions) easier.
* set::oper-only-stats is now a warning
* except tkl is auto-transformed into except ban and is now a warning
Both warnings contain clear instructions on what to do to get rid of
the warning message.
This can still be enabled during ./Config by answering to the last question:
--with-asan
But it is no longer enabled by default since it causes a slowdown of X and
increases memory by a factor Y.
until you restart the server.
Yeah it's really too much hassle atm to make that particular setting
/rehash'able, this will probably never change.
Fortunately changing that is rather rare. At least printing the
warning should help those users doing it.
* Cannot use include within an @if
..but you can just use an include and then within that file use
an if, to work around it.
* Cannot use loadmodule within an @if
For both this is because include & loadmodule are processed before
the rest. I think most people will be fine with those restrictions,
though.
reported in https://bugs.unrealircd.org/view.php?id=5281
It was not removing parts properly if an if didn't match,
leading to a use-after-free bug on-boot (or on rehash).
In the process I renamed config_entry_free to config_entry_free_all
since that is what it does. And I created a new config_entry_free(ce)
to free only 'ce' stuff... which is what we want from the
preprocessor.
if you are running a mixed U4 and U5 network, but it solves the situation
where a knock-flood is only detected locally. Since KNOCK usage isn't
that common and flooding is worse than double notices during the
transition period, I went with this change..
to exist and needs to be -n now.
Previously the logic was the wrong way around which made it message
through +n channels and not work if you were actually in the channel.
Fun.
for the user. Otherwise with post-connect SASL authentication you will
have different login information on server X compared to server Y
(the server with the user on it was always correct, though).
Also, add a function called user_account_login() which is used by both
SVSMODE/SVS2MODE and SVSLOGIN to send ACCOUNT messages to the channel.
This too was missing for SVSLOGIN (post-authentication SASL).
For this fix to be 100% effective, you need 100% UnrealIRCd 5.
in a sending loop if you used a services logging channel.
Reported by The_Myth in https://bugs.unrealircd.org/view.php?id=5469
The same bug was reported and seemingly fixed before, but wasn't
actually.
present in UnrealIRCd 4, and possibly in 3.2.x as well.
This changes:
SILENCE
:irc1.test.net 271 self self evilperson!*@*
To:
SILENCE
:irc1.test.net 271 self evilperson!*@*
under the NetworkService account, rather than LocalSystem (SYSTEM).
Something along those lines was suggested long ago in:
https://bugs.unrealircd.org/view.php?id=2330 with a patch
from BuHHunyx.
The more recent pull request from AlexandraBryant suggested to use
the NetworkService account and also fixed the (major) problem with the
original patch that caused UnrealIRCd to hang for 15 seconds when
UnrealIRCd was started in GUI mode (non-services mode).
The installer was changed to automatically set the appropriate
permissions on the UnrealIRCd 5 folder if "Install as a service"
was selected. This so NetworkService can write, otherwise it would
be unable to copy modules to tmp\, write to log files, etc. etc.
We print a clear warning if you manually install the service at
a later stage, suggesting to run the installer instead or to
manually change the permissions.
Better error checking and reporting was added when running 'unrealsvc'
and when we are unable to connect to the service manager. This is
much more common nowadays as you need elevated admin permissions.
checking repositories and downloading C files (this was a TODO item).
Give a clear hard error if ALL repositories failed
(failed to connect, download or parse).
Make a few commands work regardless of repository status.
In fact, these don't connect to repositories at all since they
don't need to. Thus, these commands are always available:
./unrealircd module [uninstall|generate-repository|parse-c-file]
of which only 'uninstall' is of importance for end-users.
Finally, make parse-c-file print a better error in case the file
could not be opened. Note that this command is only there for
module developers and repository managers, not end-users.
/** Calculate the cloaked host for a client.
* @param client The client
* @param curr The real host or real IP
* @param buf Buffer to store the new cloaked host in
* @param buflen Length of the buffer (should be HOSTLEN+1)
*/
void make_cloakedhost(Client *client, char *curr, char *buf, size_t buflen)
all known flags as well. So you can now add stats via modules.
Only the stats help is currently missing if you do so.
=> Moved dccdeny stats to dccdeny
src/parse.c. Also re-order functions in parse.c so they appear in
logical order (1->2->3->4) rather than various helper functions first
and some random order.
https://bugs.unrealircd.org/view.php?id=5453
It had the match_spamfilter() logic reversed. I audited all other
calls to the function as well and they are fine.
Also, CHGHOST CHGIDENT CHGNAME SETHOST SETIDENT SETNAME are now
tested by the test framework.
session after a 15 seconds timeout. The exact timeout value can be
changed by adjusting set::sasl-timeout, which should be (quite a bit)
less than set::handshake-timeout by the way. 15<30 now, so fine.
than scattered checks - which are sometimes different - everywhere in
the source code.
Also extban handler "is_ok" was being called with EXBTYPE_EXCEPT
rather than EXBTYPE_INVEX for +I. (Not reported by anyone)
deal with servers with different set::allowed-channelchars settings:
* We reject the link if set::allowed-channelchars settings differ between
UnrealIRCd 5 servers.
* For the case where you have a mixed network consisting of UnrealIRCd 4.x
and UnrealIRCd 5.x servers we try not to desync, BUT will not allow
anyone to join the invalid channels locally. For IRCOps a message is
printed with additional information on such a failed JOIN attempt.
See https://www.unrealircd.org/docs/Set_block#set::allowed-channelchars
for the different settings, which are best and U4<->U5 advice.
CAN_SEND_TO_USER rather than HOOKTYPE_PRE_USERMSG (which is now removed).
As for the numeric change: this makes it much easier for client devs.
You rarely need to differentiate in the client code between the various
causes. One only cares about detecting that the message was not sent and
that the user needs to be informed.
This replaces various NOTICEs, ERR_NOCTCP, ERR_NONONREG etc. with just the
new numeric 531, which is taken from InspIRCd. The syntax is:
:server 531 yourname targetname :reason for the block
This makes it similar to numeric 404 (ERR_CANNOTSENDTOCHAN) that is used to
indicate that a channel message was blocked.
For module devs, the new hook CAN_SEND_TO_USER prototype is:
int hooktype_can_send_to_user(Client *client, Client *target, char **text, char **errmsg, int notice);
You can replace the text via this, by setting *text in your function.
You can block the message, by returning HOOK_DENY. If doing so, then
you must also set *errmsg to an appropriate value.
Do not send any error message to the user! UnrealIRCd will take care of
sending the error message for you, if you set *errmsg.
Only if you need something special you could violate this rule, but
preferably not!
As you can see, CAN_SEND_TO_USER works just like CAN_SEND_TO_CHANNEL.
1) HOOKTYPE_CAN_SEND is now called HOOKTYPE_CAN_SEND_TO_CHANNEL
The arguments and return values are unchanged
2) similarly can_send() is now called can_send_to_channel()
3) If you want to block or alter a message you must now
use HOOKTYPE_CAN_SEND_TO_CHANNEL and return HOOK_DENY from
there with an appropriate *errmsg filled (see nocolor and
many other modules for an example)
4) You CANNOT use HOOKTYPE_PRE_USERMSG anymore to block a message.
I actually wanted to rip this hooktype out entirely, but
delayjoin needs it. HOOKTYPE_PRE_USERMSG is only useful for
notification that a message is going to be sent BEFORE it is
actually sent (which is exactly what delayjoin needs, so it
can send a JOIN if the user is currently invisible).
5) This is all to make things more clean:
* HOOKTYPE_PRE_USERMSG is only for delayjoin
* HOOKTYPE_CAN_SEND_TO_CHANNEL is used for exactly what the
name implies. You can also change the message text there,
such as for +G, +S, etc.
This so I - and others - don't constantly have to wonder whether the client
is called sptr, cptr or acptr in a simple routine.
Insane --> 212 files changed, 6814 insertions(+), 6945 deletions(-)
Couldn't just mass-replace of course since there are places where there
are multiple clients involved. So had to check each function.
Also renamed some 'acptr' to 'target' and such.
I will write a page with new style rules later.. but in short if there is
only 1 client involved it will now be called 'client'.
anymore if you run latest anope 2.0.6. You need the fix from Feb 9, 2019:
https://github.com/anope/anope/commit/da6e2730c259d6d6356a0a948e85730ae34663ab
(.. which also fixes SASL problems with anope + UnrealIRCd 4 by the way)
or just run anope latest git (2.0 branch).
Not sure about atheme... should test this.
Technical details: we used a pseudo ID / sasl cookie until recently,
this has always been planned to be phased out when we got UID's.
I didn't phase it out in U4 (but could have done so) but just did now in U5.
This simplifies everything as now you can just refer from the services
side to the user with the UID/SID. This also makes it so services can now
target the user in other functions as well, like NOTICE.
(Feel free to request other functions if something isn't working)
Merge check_init and AllowClient into one single AllowClient()
and make it use the more logic 1 and 0 return values for allow / deny.
Similarly, use logic 1 / 0 return values for verify_link.
Module coders:
HOOKTYPE_CHECK_INIT and HOOKTYPE_PRE_LOCAL_CONNECT, changed the
return value, you should now use HOOK_*, eg HOOK_DENY to stop
processing (eg client killed).
that deal with finding TKL's or spamfilters etc.
More will likely follow, to make things more logical.
Also, run_spamfilter -> match_spamfilter
place_host_ban, can_privmsg, check_dcc, find_tkline_match all impacted.
code changes in UnrealIRCd itself:
1) Clients are no longer freed directly by exit_client. Most fields
are freed, but 'sptr' itself is not, so you can use IsDead() on it.
2) exit_client now returns void rather than int
3) ALL command functions return void rather than int.
Of course this also affects do_cmd, command overrides, etc.
This is a direct consequence of the removal of 'cptr' earlier, as that
was used to signal certain things that are now no longer possible
(and it raises the question if things were always correctly signaled
in the first place, so may fix some bugs).
It also makes the code more resillient against cases where you forgot
to check if the client was freed. Still, you are encouraged to do an
IsDead(sptr) if you are calling functions that may kill clients,
such as command functions or things that may use spamfilter.
More changes will follow, such as the removal of FLUSH_BUFFER.
** Exit this IRC client, and all the dependents (users, servers) if this is a server.
* @param sptr The client to exit.
* @param recv_mtags Message tags to use as a base (if any).
* @param comment The (s)quit message
* @returns FLUSH_BUFFER is returned if a local client disconnects,
* otherwise 0 is returned. This so it can be used from
* command functions like: return exit_client(sptr, ....);
'sptr' is sufficient and in most cases the only one you should care about.
Should you need it, you can access sptr->direction in cases where you
need the old information (usually only for some sendto_* functions
and some protoctl checks), so 'cptr' was redundant too.
[!] This change likely introduces some bugs. This was many hours of work.
I only cut some corners in 4 functions, which will be fixed at a later
stage..... yes, more major changes to come.
On the plus side, I likely fixed some bugs in the process. Situations
where cptr vs sptr usage was incorrect. Eg using cptr->name (near server)
when sptr->name should be used (the actual source server), etc....
In such a case we refuse to run since the consequences are too big.
(Actually I may change the non-UTF8 channel warning to an error as well,
right now it isn't.. simply because I cannot read a certain setting)
From both the non-UTF8 channel and user warning/error, we now refer to:
https://www.unrealircd.org/docs/WebSocket_support#websockets-and-non-utf8
which contains a bit more detailed information as to the WHY.
how you use websockets in the configuration file:
In addition to loading the websocket module you now ALSO have to mark
specific listen blocks with listen::options::websocket, and you have
to specify a type as well. Example:
listen {
ip *;
port 1234;
options {
websocket { type binary; }
}
}
The type 'text' is compatible with kiwi although this is currently
completely untested. Also I should add something to the release notes
about this change. Tomorrow...
We actually have 3 possible settings of set::allowed-channelchars:
utf8: Channel must be valid UTF8, this is the new default
ascii: A very strict setting, for example in use at freenode,
the channel name may not contain high ascii or UTF8
any: A very loose setting, which allows almost all characters
in the channel name. This was the OLD default, up to and
including UnrealIRCd 4. It is no longer recommended.
For most networks this new default setting of utf8 will be fine, since
by far most IRC clients use UTF8 for many years already.
If you have a network that has a significant portion of chatters
that are on old non-UTF8 clients that use a specific character set
then you may want to use set { allowed-nickchars any; }
Some Russian and Ukrainian networks are known to need this.
Devs: src/utf8.c has been added which will be used by this and
by other functionality later.
which specifies the time in milliseconds rather than seconds. This
allows for additional precision, or at least multiple calls per second.
The minimum allowed every_msec value is 100 at this time.
The prototype is now: EventAdd(Module *module, char *name,
vFP event, void *data, long every_msec, int count);
crashes (has a core file) to the crash bug report.
Also, disable leak detection since this is too noisy and would cause
a core dump each time + bothering the user to submit a crash report
+ send this crashreport etc. We still enable this in our own tests
though, but not for end-users.
which would be too much coding effort for such an unusual event.
(Reloading is fine though, for eg upgrading-on-the-fly)
Issue reported by westor in https://bugs.unrealircd.org/view.php?id=5416
that was not supposed to be committed :D
It would also warn about if'd out blocks, which is confusing,
so best to disable the warning altogether for now.
Also, you can escape a $VAR to $$VAR if you really just mean $VAR literally.
Such usage would be very rare though.
Note that the parser is smart enough to know that $var is never a
global variable, it only warns for valid variable names like $VAR and
even then only if it's at the end or has whitespace/dot/comma/etc.
So... false positives should be extremely low...
the variable names to UPPERCASE, digits and underscores (A-Z0-9_).
This makes them easily distinguishable from other items in the conf,
so they don't clash with for example $ip in blacklist::reason.
The @define confusion was reported by Gottem and westor.
extern int strnatcmp(char const *a, char const *b);
extern int strnatcasecmp(char const *a, char const *b);
This will be handy for version comparisons. For example they will
return -1 (=lower) for things like ("1.4.9", "1.4.10"), unlike strcmp.
Also, some loosely related spelling fixes elsewhere.
to be a bit less ugly. The module is loaded by default so you can
still use set::options::identd-check like before, even though I
hate ident... it's old shit... still, other's seem to like it.
More changes will follow later. There is still some ident stuff
in the core at the moment and the module is currently PERM, which
largely (but not entirely) defeats the purpose of being a module.
That will be fixed at a later time as well.
MOD_UNLOAD. And MOD_HEADER(xyz) is now MOD_HEADER even without ()
since this isn't a function, really.
To make things understandable I added the following to the
developer section of the release notes:
* The module header is now as follows:
ModuleHeader MOD_HEADER
= {
"nameofmodule",
"5.0",
"Some description",
"Name of Author",
"unrealircd-5",
};
There's a new author field, the version must start with a digit,
and also the name of the module must match the loadmodule name.
So for example third/funmod must also be named third/funmod.
* The MOD_TEST, MOD_INIT, MOD_LOAD and MOD_UNLOAD functions no longer
take a name argument. So: MOD_INIT(mymod) is now MOD_INIT()
the chanmodes/delayjoin module must be named chanmodes/delayjoin
in the module header.
This because currently we have two module names for each module,
one is the name from the MOD_HEADER and the other is the
relative path, such as used by loadmodule and is_module_loaded().
This commit also (not entirely, but practically) breaks loading
of modules outside the regular modules path. I don't think that's
a problem, although it could use a bit more documentation.
REQMODS Gmodname:version ....
to:
SMOD G:modname:version ....
Also, call the module require-module to be consistent with the
naming of the configuration directive.
Not sure yet of the set name, but call it set::require-module for
now as well.
This so we have a few simple concepts:
Client: this can be a user, server, or something unknown yet
Then the type of clients:
User: this is a user, someone with a nick name.
Server: this is a server
Etc.
as cptr->from is NOT (necessarily) the server where cptr is connected to.
So we now call it cptr->direction since it indicates the directly connected
server (or &me)... in other words: the direction of the client path.
old authentication types that are already deprecated in UnrealIRCd 4.x.
They don't contain any rounds which means they can be cracked at a rate of
millions per second. Use the secure hashing type 'argon2' instead
(or, if you must, use the less secure 'bcrypt' type).
including things like CallCmdoverride() to CallCommandOverride().
Type changes like aTKline -> TKL and many more (in particular
aSomething to Something etc. such as aWatch to Watch) but these are
less used by 3rd party module coders.
aChannel to Channel, and some more. Third party module coders will
love this. But.. it makes things more logical and the doxygen output
will look more clean and logical as well.
(More changes will follow)
Use a more simple hashing algorithm and one that uses 64 bits,
don't allocate any memory dynamically, just use an int64_t.
Also, only do the hashing if 'r' is actually enabled in +f
on the channel, as otherwise it's pointless.
Also get rid of the TS parameter in there, which nobody uses anyway.
It didn't even refer to the channel TS.. quite confusing..
it used user->since... so it seems it was against crossing users
(nick changes)... well, we have UID for that now.
except ban in config).
If you want to play with exceptions, type /ELINE for information.
For the configuration file it is important to know that 'except tkl'
is now called 'except ban'.
Also if you do not specify an except ban::type we now default to
exempt from all regular server ban types (but not qline, spamfilters,
blacklist or throttling)
Still need to fix some FIXME/TODO items and things haven't been
fully tested yet, so server sync issues or crashes are still possible.
Release notes will be updated another day as well..
src/modules/tkl.c is the main one).
Also move DB writing/reading functions to src/misc.c so they can be
removed out of channeldb and tkldb.
Important note to current tkldb users:
Unfortunately due to the major cleanup I had to remove upgrading
for previously saved tkl db files. That seemed not worth the effort
for maybe <15 current users or so. It also makes the tkldb code
a lot more cleaner. Otherwise it would be a huge mess.
Currently a FIXME item: spamfilter support in RMTKL.
and remove old dependency field (never used, was always NULL,
broken since 3.2.x)
I'll add some constraints later on things like names and versions.
IOTW: more changes to follow, don't mass update your own mods yet.
Disable these warnings, though:
C4267: downgrade of size_t to int and such. pointless...
C4101: unreferenced local variable
C4018: signed/unsigned mismatch
C4244: implicit conversions with "possible loss of data".
there are 75+ of them and they are likely all harmless
and/or intentional (usually plain obvious too)
C4996: fixme! warnings about deprecated functions, currently only for GetVersion..
setting the default class::sendq that pretty much everyone overrides
in class (isn't this even required? ;D).
Rename to DEFAULT_SENDQ since we have DEFAULT_RECVQ too.
explicit cast to (long long). On *NIX we could get away with
lazily assuming time_t is of the same length as long (and use %ld),
even though the specification says nothing about it.
Unfortunately on Windows things are not that simple:
'time_t' is 'long long' (64 bits) and both 'int' and 'long'
are 32 bits, even when compiling in 64 bit mode.
This problem could be 'fixed' in multiple ways:
One way would be to minimize the usage of time_t and use 'long long'
or 'uint64_t' everywhere for variables to minimize casting later.
I, however, chose to maintain 'time_t' for most of time grabbing
and time calculations (eg: delta), and do the explicit cast in
any printf-like functions that may be there.
Both solutions work. I mostly like the explicit time_t look, so one
can immediately recognize a variable relates to time.
are IRCOp-only now, they will always be removed on deoper.
-extern Snomask *SnomaskAdd(Module *module, char ch, int unset_on_deoper, int (*allowed)(aClient *sptr, int what), long *mode);
+extern Snomask *SnomaskAdd(Module *module, char ch, int (*allowed)(aClient *sptr, int what), long *mode);
32 to 64 bit transition, visual studio 2019 and some directory name
updates as we now put all the shit in c:\dev\unrealircd-5-libs,
or c:\projects\unrealircd-5-libs in case of buildbot..
1) Clean up check_for_chan_flood()
2) Make the new repeat action kick by default (instead of forcing 'b'
if no action is specified)
3) Also make repeat work with timed bans
Note that the labeled-response implementation currently requires
'batch' and will always start a BATCH if there is any response.
Later on we can implement a simple queue so we don't have to
start a batch for 1-line responses (which works, but looks a bit
silly if you look at raw server traffic). That may be after alpha1,
though, as there are more (important) things to work on right now.
so you can use set::restrict-commands without having to loadmodule.
Restrict the LIST and INVITE commands in the example.conf, which is
often a good idea. Finally, document the configuration/usage at:
https://www.unrealircd.org/docs/Set_block#set::restrict-commands
of match_simple() and match_esc(). So, developers, be aware, this is how
you should use the function in a correct way:
if (match_simple("*fun*", str))
printf("It was fun\n");
Rationale:
I've always been annoyed by the inversed logic, even though it was similar
to strcmp. So I've reverted it.
I could have chosen to maintain match() rather than this match_simple()
name, but this way I force (3rd party module) devs to update their function,
while otherwise everything would mysteriously fail due to the inverted logic.
I suppose what is and what is not an API can be considered a bit arbitrary
but for us it is the stuff we expose via the module api. We now have:
api-clicap
api-command
api-event
api-extbans
api-extcmodes
api-history-backend
api-isupport
api-mtag
api-umodes
I needed the target for echo-message, and also in the history module we no
longer save to the history any @#channel messages, since otherwise they
could be played back to people we shouldn't see them ;)
So rename src/modules/m_*.c to src/modules/*.c and update makefiles
and modules.default.conf. Also remove m_ at various places in the
source files, but not the CMD_FUNC(), just the module name.
if (m->clicap_handler && (acptr->local->caps & m->clicap_handler->cap))
return 1;
... so if messagetaghandler->clicap_handler is NULL then this won't be 1.
UnrealIRCd already protects (for maaaany years) with ping cookies against
this attack. Making the m_nopost redundant.
Also, another module may be more useful (more on this soon...).
explicitly do not want to remember any channel history, such as on
a hub server to save memory.
Also, on Windows, ensure to compile all history_backend_*.c
This determines when UnrealIRCd will use broadcast instead of multicast
for delivering channel messages to servers.
The default is 'auto' which uses multicast but switches to broadcast
when channel mode +H is set. This is what people should normally use.
If you set it to 'never' then +H will not work properly if there are
servers with 0 users on them.
and not just the operating system.
This makes us use SSL_CTX_set_min_proto_version(), which unfortunately is
a less fine-grained control for disabling specific SSL/TLS versions.
However, after that we use SSL_CTX_set_options with SSL_OP_NO_xxx.
The latter is deprecated though. Will revisit this change before U5 release..
Main difference is that the curve used for ECDHE is fixed at prime256v1
rather than a list of multiple choices (this due to an openssl 1.0.1
limitation).
[skip ci]
systems without explicit_bzero. Current usage is only in the PRNG which
is not very important anyway. We can re-visit later by attempting to
provide a fallback portable version, but from what I've seen this is
pretty ugly.
to enter the private key password when UnrealIRCd is (re)started.
Similarly, remove all references to it on Windows as well, where people
thought clicking "Encrypt private key" was a good idea. Can't blame them,
it sounds good on first sight :D
[skip ci]
LoadPersistentPointer(modinfo, removefld_list, floodprot_free_removefld_list);
SavePersistentPointer(modinfo, removefld_list);
The above example was for a pointer, there are also functions for int and long,
which are even more simple:
LoadPersistentInt(modinfo, somevar)
SavePersistentInt(modinfo, somevar)
and
LoadPersistentLong(modinfo, somevar)
SavePersistentLong(modinfo, somevar)
both are untested, but will be tested soon...
make a mistake in the module so we can upgrade it on-the-fly.
Or if someone wants to get rid of it.
TODO: consider abstracting the saving/restoring of vars.
(malicious) server traffic.
Also seems we have a behvior change here: has_voice and such returned
1 for servers, now it returns 0. I can live with that, but may cause
more issues.
These are just remnants of the past, when +a was called channel protection.
It is called channel admin since as long as I can remember, and in 90%
of the code and documentation it is called that way.
in case of a change in the quit comment, such as color stripping / blocking.
The default is 'no', but some users may like this to be 'yes' so things like
+S only affect the channel and not the quit for all channels.
This hereby also lays the groundwork for some next commits of 'i' :)
The configuration item name may still change if I think of a better one....
Make local spamfilter blocks use this too. Already did so for
ban xxx types that will cause kline/gline/zline and qline.
This also simplifies handling in the tkldb module.
file that cannot be deleted via commands such as /KLINE -...
And transform some ban XX entries to use the TKL system
TODO: test & rip out the old stuff
Since UnrealIRCd 4 (and probably before) our instructions always mentioned
that you should not build or run UnrealIRCd as root.
Even system integrators are unlikely to build as root, but just in
case, the safety the check is in ./Config and not in ./configure.
Also, DoAccess() was already commented out in UnrealIRCd 4 or something.
This results in an empty finish_auth() function but that should be OK,
as ident checking takes place before parsing any other input IIRC.
If everything goes correctly then after reading all TKL entries we
should be at the end of file. If there is still data after that,
something went wrong... quite wrong.. :D
This, rather than having the module not loaded at all, which could mean,
especially if missed the warning on boot, that you run for weeks or
months without having your TKL's stored, which would be a shame ;)
Also a failure to rename() is not fatal, as it likely means that we
don't have permissions, in such a case you will see a repeated error
every X minutes due to the write, which is good.
will not be called. This is used, for example, by m_cap when the CAP LS
handshake is still in progress. Modules can add their own requirements
as they see fit.
Note that, as for (CAP) functionality, this adds nothing new, it just
implements it in a cleaner way, rather than all over the place,
like in UnrealIRCd 4.x.
and has various outstanding crash and 100% CPU issues.
We have been encouraging the PCRE2 engine since the start of
UnrealIRCd 4 already.
TRE is being phased out of U4 by the end of the year, so we can
safely remove it in U5 already.
Such a variable suggests that we will never read past that, but that
is not the case, since we (correctly) assume that the buffer is
NUL terminated, which is ensured by dbuf_getmsg().
The 'length' is still available for informational purposes, to avoid
strlen()'s at various places.
Hm, I guess length can cause the same confusion as bufend, but still..
I like it better :D
For example, msgid / message-ids is not a CAP, while server-time is.
There mere fact of something being in CAP or not shouldn't cause
something to be in different directories ;).
Early commit, still cleaning up to do.
But what works is:
$define SERVER "hub.example.org"
$if SERVER == "hub.example.org"
link .... {
....
}
$endif
$if defined(SERVER)
....
$endif
And also we have mod-loaded() which even works half-way in a block
such as in helpop:
help Chmodes {
[..]
$if module-loaded("chanmodes/stripcolor")
" c = Block messages containing mIRC color codes [o]";
$endif
$if module-loaded("chanmodes/noctcp")
" C = No CTCPs allowed in the channel [h]";
$endif
};
As said, still need to cleanups and there are some limitations.
Also the idea is to be able to use defined values in variable names/values
but that has not yet been implemented.
You now call it with a path like is_module_loaded("extbans/timedban").
This, among other reasons, so you can differentiate between modules with
the same name, such as "usermodes/noctcp" and "chanmodes/noctcp".
This also includes buffer modifications to have a larger read buffer
and IRCv3 implementations (partial or not) for:
labeled-response, msgid, server-time, batch and account-tag.
As said, it is the initial and partial implementation.
There are still various FIXME's and TODO's, the API of various
functions may still change (actually that is true for the next
months, even) and some stuff is currently in the core that will
be moved to modules.
always as new users (regardless of reputation), causing the protection
to kick in too quickly for the poor new users. This was noticeable
after for example one server died and new users reconnecting massively
to the remaining servers. Reported by Lord.
have already fully authenticated the server (but when it technically is
not fully linked as a server yet, eg post-EAUTH but pre-SERVER).
Also, send ERRORs to junk snomask from untrusted sources. After all,
the junk snomask is precisely there to enable briefly to debug issues.
In case of link errors we always advice to check BOTH sides of the link
as an IRCOp, and this advice still stands. This may just help a little
for people who do not follow our advice.
password types (eg: plaintext on one side, spkifp on the other side).
Refer to https://www.unrealircd.org/docs/FAQ#auth-fail-mixed
Also, unrelated to the above, don't say "Bad password?" if the
password type is not of type plaintext, since it would be confusing.
Nowadays these are pretty much never proxy attacks. Only scanners and
crawlers trying HTTP commands on IRC connections.. which isn't even that
weird anymore since people tend to open up port 443 for SSL/TLS IRC
to bypass firewall restrictions.
not found then this was not treated as a fatal error. Now it is, since
you will fail later in the installation process when a certificate file
is being made (resulting in mysterious 'req: command not found' errors).
Also, improve the error message both for the missing openssl library
and openssl binary case.
For example for Windows users, or for *NIX users where the automated
patching of the spamfilter.conf did not work.
I've tried to make the error message as clear and big as possible
and the wiki article as clear as possible as to what the user needs
to do. Not much more I can do.... :)
'posix' to 'regex' if the user is using the exact same spamfilter.conf
that shipped with UnrealIRCd 4.x until now. Otherwise, we do not
update anything. Also, custom spamfilters in this file are not touched.
Let's hope this will apply to most of our users to ensure that they
will have no or less issues with the 'posix' to 'regex' conversion
process.
This is mostly to guard 3rd party module writers against making
such a mistake. Up to now such a mistake would silently corrupt
memory without warning or error. That is, until you crashed :D.
usually the fast badwords system is used instead)
* Code deduplication in src/modules/{chanmodes,usermodes}/censor.c
to src/match.c -- which may be moved later again to efuncs.
* Add --without-tre:
This means USE_TRE will be enabled by default right now
but if using --without-tre it will be undef'ed. This so we
can prepare for the TRE phase-out in 2020.
* Remove include/badwords.h, put contents in include/struct.h
that these are just old examples from the year 2005.
Also, no longer include spamfilter.conf from the example*conf by
default as they do not contain any useful spamfilters nowadays.
is another warning being triggered.
-copy paste comment from configure.ac-
We check for the -Woption even though we are going to use -Wno-option.
This is due to the following (odd) gcc behavior:
"When an unrecognized warning option is requested (e.g.,
-Wunknown-warning), GCC emits a diagnostic stating that the option is not
recognized. However, if the -Wno- form is used, the behavior is slightly
different: no diagnostic is produced for -Wno-unknown-warning unless
other diagnostics are being produced. This allows the use of new -Wno-
options with old compilers, but if something goes wrong, the compiler
warns that an unrecognized option is present."
Since we don't want to use any unrecognized -Wno-option, we test for
-Woption instead.
The new question in ./Config now defaults to 'auto' (both for new installs
and for upgrades). You can still specify a manual limit but it is no longer
recommended.
A MAXCONNECTIONS of 'auto' means - at present - that UnrealIRCd will try
to set a limit of 8192. This is quite a bump from the original 1024.
On systems where this is not possible we will simply use the highest amount
possible, such as 4096 on many systems, or 1024.
In fact, we now no longer error when MAXCONNECTIONS is higher than the
'ulimit -n' limit but will adjust ourselves to the limit.
Only if the effective limit is below 100 we will print out a fatal error
since running in such a scenario is highly discouraged.
The reason for this change is that nowadays with drone attacks we may need
to be able to handle more concurrent sockets. Also, many Linux distro's
have a default setting of unlimited or 4096 nowadays, out of the box.
For people packaging UnrealIRCd (not end-users):
The ./configure --with-fd-setsize=xx option was removed and the
optional(!!) --with-maxconnections=xx option has been added.
We recommend you NOT to pass this option. Not passing it means that
the previously mentioned 'auto' mode will be used, which is likely
best for most users.
Module coders:
Although it is unlikely you accessed the 'MAXCLIENTS' variable,
if you did, it is now called 'maxclients' (lowercase) since it is
adjusted at runtime and no longer a macro.
encouraged to use CMD_OVERRIDE_FUNC(override_xyz) rather than declaring
the function themselves. This works similar to CMD_FUNC(somecmd).
Example:
/* Forward declaration */
CMD_OVERRIDE_FUNC(override_xyz);
[..]
MOD_LOAD(somemodule)
{
CmdoverrideAdd(modinfo->module, "XYZ", override_xyz);
[..]
CMD_OVERRIDE_FUNC(override_xyz)
{
/* Do something useful here */
that need to be visible from the outside of the .DLL (symbol export).
Long story short: you never need to use this yourself in a module.
Where needed it is already handled by UnrealIRCd.
enough to clean it up. Also, remove PROTOCTL -<option> support, which is
not used by anything and was only supported on a handful of options
anyway. Also remove some debugging and PROTOCTL_MADNESS.
Finally, add a reference to the technical documentation.
triggered by doing quick server connects (crossing requests), something
that the PROTOCTL SERVERS= code is supposed to prevent (it should be
safe to connect to X servers at the same time, even every second).
Previously various information was only available for directly attached
servers, since it is communicated via PROTOCTL.
Now, we will also communicate information about leafs behind us.
IRCOps can use the /SINFO command to see these server features.
Services codes don't need to do anything, or at least are not expected
to do anything. They can still receive the information and do something
with it, of course...
Read the following technical documentation for full information,
as it will outline very specific rules for using the command S2S:
https://www.unrealircd.org/docs/Server_protocol:SINFO_command
I was wondering why the handshake took 4 seconds for a client which
authenticates using SASL. Turns out that fake lag was kicking in due
to the many "CAP req" commands combined with the other handshake stuff.
Now the first 15 (or so) "CAP" requests are "free", without fake lag.
of targets accepted for a command, eg /MSG nick1,nick2,nick3,nick4 hi.
Also changed the following defaults (previously hardcoded):
* PRIVMSG from 20 to 4 targets, to counter /amsg spam
* NOTICE from 20 to 1 target, to counter /anotice spam
* KICK from 1 to 4 targets, to make it easier for channel operators
to quickly kick a large amount of spambots
See https://www.unrealircd.org/docs/Set_block#set::max-targets-per-command
(actually still need to write the documentation)
maximum number of conversations a user can have with other users at the
same time. Until now this was hardcoded at limiting /MSG and /INVITE to
20 different users in a 15 second period. The new default is 10 users,
which serves as a protection measure against spambots.
See https://www.unrealircd.org/docs/Set_block#maxcc for more details.
such as "WHO +s serv.er.name" to "WHO serv.er.name s".
It also does advanced transformation such as "WHO -m z" to "WHO -z m"
**copy paste from comment in code**
Flag a: user is away << no longer exists
Flag c <channel>: user is on <channel> << no longer exists
Flag g <gcos/realname>: user has string <gcos> in his/her GCOS << now called 'r'
Flag h <host>: user has string <host> in his/her hostname << no change
Flag i <ip>: user has string <ip> in his/her IP address << no change
Flag m <usermodes>: user has <usermodes> set << behavior change
Flag n <nick>: user has string <nick> in his/her nickname << no change
Flag s <server>: user is on server <server> << no change
Flag u <user>: user has string <user> in his/her username << no change
Behavior flags:
Flag M: check for user in channels I am a member of << no longer exists
Flag R: show users' real hostnames << no change (re-added)
Flag I: show users' IP addresses << no change (re-added)
**end of paste**
Of course we cannot convert 100% from classic UnrealIRCd WHO to WHOX-style
because things like "WHO +m r" could mean either "search for +m in realname" (WHOX)
or "search for +r in modes" (classic). In cases like this we assume WHOX, so to not
break any WHOX compatibility.
Added matchers: 'R' (show real host) and 'I' (show IP)
This code will need more testing, both by classic WHO and by WHOX users...
* No longer require a ! prefix for ircops to see users
* "WHO *" is no longer different than the rest
(previously in m_whox would only list users on 1st channel)
Neither is part of the WHOX specs.
not picked up by any other IRCd. The 005 tokens KNOCK MAP USERIP are
now used instead. We do not announce STARTTLS in 005 anymore as this
is way too late (post-handshake, sensitive info already sent and/or
received). Not to mention STARTTLS is not the preferred method to
setup a secure connection in the first place.
Module coders: this means CommandAdd() with M_ANNOUNCE should no
longer be used. If a 3rd party module does use it, then UnrealIRCd
will now raise a warning. In a later UnrealIRCd version the flag
is likely to be removed completely so would cause a compile error.
(I doubt any module uses this anyway... but still..)
* You can now set more custom limits. The default settings are shown below:
set {
topic-length 360; /* maximum: 360 */
away-length 307; /* maximum: 360 */
quit-length 307; /* maximum: 395 */
kick-length 307; /* maximum: 360 */
};
* A new 005 token has been added: QUITLEN. Works similar to KICKLEN.
The ability to adjust the topic length in the configuration file was
requested by Amiga600 in https://bugs.unrealircd.org/view.php?id=4692
At that place is also additional information on why there is a
"maximum" for topic length.
There's now no longer a difference between a rehash or boot.
2) Other cleanups in s_conf.c as well. Looks better now.
3) Sort the 005 tokens alphabetically. Enforcing some other 'logical order'
was futile and this makes things consistent between rehashes.
For module coders this adds some new functions, such as IsupportSet,
IsupportSetFmt and IsupportDelByName. I'll document them later.
to control synchronization of the +beI setter across server links
(that is, the feature just introduced one commit ago):
set {
topic-setter [nick|nick-user-host]; /* nick = default */
ban-setter [nick|nick-user-host]; /* nick = default */
ban-setter-sync [yes|no]; /* yes = default */
};
This also means that --with-topicisnuhost / TOPIC_NICK_IS_NUHOST
is now removed, since this now goes via set::topic-setter.
Also, moved the "first" PROTOCTL from include/common.h to send_proto()
in src/s_serv.c so the bunch of PROTOCTL lines is all in one place
(and so I could conditionally send SJSBY).
Ok, it's not entirely all in one place, PROTOCTL EAUTH is still sent
at another place (early, duh), but still..
when servers link. Thus, you can see the real setter and time also after
a netsplit (/mode #channel b). This, unlike before, when setby was
name.of.server and time was the time of the synch.
This requires the entire network to run UnrealIRCd 4.2.2 or later.
Suggested by k4be in https://bugs.unrealircd.org/view.php?id=5183
Technical details: the PROTOCTL token to enable this is "SJSBY" and see
https://www.unrealircd.org/docs/Server_protocol:SJOIN_command for more
information, in particular the last section there.
for CONFIG_LISTEN. This so a module can have custom options in
the listen block. Like all other CONFIG_* options you are supposed
to return 1 if your module handles this option and 0 if not.
From HOOKTYPE_CONFIGTEST you can also return -1 to indicate error
for an option that is handled by the module.
Note that 'cep' is passed, that is the option for the variable
that is being checked, and not the 'ce', the parent of the listen
block. If you want to access the parent, then use ce->ce_prevlevel.
The script symlinks any missing tmp/xxxx.so's to the real module name but
depends on English statements (ugly, yeah, but it works). With a non-English
locale this did previously not work so the backtrace was screwed.
do with clients that use outdated SSL/TLS protocols (eg: TLSv1.0) and
ciphers. The default settings are to warn in all cases: users connecting,
opers
/OPER'ing up and servers linking in. The user will see a message telling
them to upgrade their IRC client. This should help with migrating such
users, since in the future, say one or two years from now, we would want to
change the default to only allow TSLv1.2+ with ciphers that provide Forward
Secrecy. Instead of rejecting clients without any error message, this
provides a way to warn them and give them some time to upgrade their
outdated IRC client.
https://www.unrealircd.org/docs/Set_block#set::outdated-tls-policy
that use outdated SSL/TLS protocols (eg: TLSv1.0) and ciphers.
The default settings are to warn in all cases: users connecting,
opers /OPER'ing up and servers linking in. The user will see a message
telling them to upgrade their IRC client.
This should help with migrating such users since in the future, say one
or two years from now, we would want to change the default to only allow
TSLv1.2+ with ciphers that provide Forward Secrecy. Instead of rejecting
clients without any error message, this provides a way to warn them and
give them some time to upgrade their outdated IRC client.
https://www.unrealircd.org/docs/Set_block#set::outdated-tls-policy
* Remove LibreSSL versions that are no longer supported (2.5.x and 2.6.x).
* Add LibreSSL 2.8.x (current stable) and 2.9.x (current dev)
* OpenSSL releases only had updates in their 'letter suffixes'
preferring AES-256 over AES-128 (in contrast to the Mozilla "intermediate"
profile which prefers AES-128). Again, this only affects non-PFS cases, as
all modern clients with PFS already had CHACHA20 and AES-256 negotiated.
The portion of non-PFS clients should only be few percent, if any.
I was actually considering removing non-PFS ciphersuites but it seems a bit
early to do so, at least not without more research on affected clients.
The last parv[] array element will be NULL. Accessing any elements after
that is undefined, similar to reading past the nul byte of a string.
This poison will help catch such bugs. Without this poison your code
will also crash, now it just crashes more consistently.
Apparently Debian stretch has 20160821's version which just falls short.
20161029 already has it included. We'll now use shipped libargon2 for
versions below 20161029. Thanks to vectr0n for reporting the issue.
https://www.unrealircd.org/docs/Authentication
And "require sasl" is now "require authentication"
(the old name will only raise a warning, not cause an error)
Note that authprompt currently only does the "require authentication"
stuff and not yet the soft-xx actions. That will be something for
later this week, but I've already documented it as such (here and
there anyway).
We previously introduced the "require sasl" block which allows you to
force users from certain IP addresses to authenticate with their nickname
and password via SASL. We now offer a new experimental module called
'saslemulation' which will help non-SASL users by showing a notice and
asking them to authenticate to their account via /AUTH <user>:<pass>.
See https://www.unrealircd.org/docs/Set_block#set::sasl-emulation
Note that this is work in progress, although the functionality of
already works. Still need to do some cleaning and expand the scope.
And more testing...
* The operclass privileges have been redone. Since there were 50+ changes
to the 100+ privileges it makes little sense to list the changes here.
If, like 99% of the users, you use default operclasses such as "globop"
and "admin-with-override" then you don't need to do anything.
However, if you have custom operclass { } blocks then the privileges
will have to be redone. For more information on the conversion process,
see https://www.unrealircd.org/docs/FAQ#New_operclass_permissions
For the new list of permissions, with much better naming and grouping:
https://www.unrealircd.org/docs/Operclass_permissions
The inconsistency in the privileges was initially reported by webczat in
https://bugs.unrealircd.org/view.php?id=4771
The subsequent reorganization took two full days, so.. hopefully the
people who are using - or plan to use - custom operclasses will like the
new layout... except that they need to redo their work of course ;)
deprecated because they can be cracked at high speeds. They still
work, but a warning will be shown on boot and on rehash.
Please use 'bcrypt' or (even better) the new 'argon2' type instead:
"./unrealircd mkpasswd argon2" or "/mkpasswd argon2 passwd" on IRC.
Also, not in release notes because it would take up too much text:
Unix crypt is a bit more complicated: most types are outright 'bad',
while other types have reasonable security similar to 'bcrypt'.
To be honest these people should probably use 'argon2' since it's
a lot better. Then again, warning about this when it's still such
a common hashing method (now, in 2018) may be a bit overzealous.
So: not warning about crypt types $5/$6 which use SHA256/SHA512
with normally at least 5000 rounds (unless deliberately weakened
by the user), but we do warn about other crypt() usage.
Also, mkpasswd support for those deprecated types has been removed since
there's no good reason to generate new password hashes with these.
Also, make this the default for './unrealircd mkpasswd'.
The Windows version also works.. I just need to create a new library
package, will be done later today or tomorrow.
https://bugs.unrealircd.org/view.php?id=5116
Note that both }; and } forms are accepted now, even mixed, and this
will not raise a warning or error.
I've always found it odd that we required a ; after }. In a language
like C for typedef structs it has some meaning since there could be
an alias between the } and the ;, but in UnrealIRCd there's no such
thing.
however it turns out they were accidentally reversed.
This is now corrected: highest number = highest prioty.
Reported by Gottem in https://bugs.unrealircd.org/view.php?id=5162
This was and still is the default, set::check-target-nick-bans 'yes', however
the feature was broken since UnrealIRCd 4.0.0 (-betaX) by commit
709c7e890e. Reported by PeGaSuS and St3Nl3y.
This module will detect and stop spam containing of characters of
mixed "scripts", where some characters are in Latin script and other
characters are in Cyrillic.
This unusual behavior can be detected easily and action can be taken.
loadmodule "antimixedutf8"; /* or third/antimixedutf8 */
set {
antimixedutf8 {
score 5;
ban-action block;
ban-reason "Possible mixed character spam";
ban-time 4h; // For other types
};
};
[](https://travis-ci.org/unrealircd/unrealircd)
[](https://ci.appveyor.com/project/syzop/unrealircd/branch/unreal40)
@@ -23,131 +22,78 @@ dnl Save CFLAGS, use this when building the libraries like c-ares
orig_cflags="$CFLAGS"
dnl Save build directory early on (used in our m4 macros too)
BUILDDIR="`pwd`"
AC_SUBST(BUILDDIR)
BUILDDIR_NOW="`pwd`"
dnl Calculate the versions. Perhaps the use of expr is a little too extravagant
# Generation version number (e.g.: X in X.Y.Z)
UNREAL_VERSION_GENERATION=["4"]
UNREAL_VERSION_GENERATION=["5"]
AC_DEFINE_UNQUOTED([UNREAL_VERSION_GENERATION], [$UNREAL_VERSION_GENERATION], [Generation version number (e.g.: X for X.Y.Z)])
# Major version number (e.g.: Y in X.Y.Z)
UNREAL_VERSION_MAJOR=["0"]
UNREAL_VERSION_MAJOR=["2"]
AC_DEFINE_UNQUOTED([UNREAL_VERSION_MAJOR], [$UNREAL_VERSION_MAJOR], [Major version number (e.g.: Y for X.Y.Z)])
# Minor version number (e.g.: Z in X.Y.Z)
UNREAL_VERSION_MINOR=["19"]
UNREAL_VERSION_MINOR=["4"]
AC_DEFINE_UNQUOTED([UNREAL_VERSION_MINOR], [$UNREAL_VERSION_MINOR], [Minor version number (e.g.: Z for X.Y.Z)])
# The version suffix such as a beta marker or release candidate
# marker. (e.g.: -rcX for unrealircd-3.2.9-rcX). This macro is a
# string instead of an integer because it contains arbitrary data.
UNREAL_VERSION_SUFFIX=["-rc2"]
UNREAL_VERSION_SUFFIX=[""]
AC_DEFINE_UNQUOTED([UNREAL_VERSION_SUFFIX], ["$UNREAL_VERSION_SUFFIX"], [Version suffix such as a beta marker or release candidate marker. (e.g.: -rcX for unrealircd-3.2.9-rcX)])
AC_PROG_CC
if test "$ac_cv_prog_gcc" = "yes"; then
CFLAGS="$CFLAGS -funsigned-char"
AC_CACHE_CHECK(if gcc has a working -pipe, ac_cv_pipe, [
echo "Apparently you do not have both the openssl binary and openssl development libraries installed."
echo "The following packages are required:"
echo "1) The library package is often called 'openssl-dev', 'openssl-devel' or 'libssl-dev'"
echo "2) The binary package is usually called 'openssl'."
echo "NOTE: you or your system administrator needs to install the library AND the binary package."
echo "After doing so, simply re-run ./Config"
exit 1
])
AC_PATH_PROG(INSTALL,install)
AC_CHECK_PROG(MAKER, gmake, gmake, make)
AC_PATH_PROG(GMAKE,gmake)
AC_PATH_PROG(GUNZIP, gunzip)
AC_PATH_PROG(PKGCONFIG, pkg-config)
dnl Check for compiler
AC_PROG_CC_C99
AS_IF([test "$ac_cv_prog_cc_c99" = "no"],
[AC_MSG_ERROR([No C99 compiler was found. Please install gcc or clang and other build tools. Eg, on Debian/Ubuntu you probably want to run the following as root: apt-get install build-essential ])])
dnl Check for make moved down, so the above compiler check takes precedence.
AC_CHECK_PROG(MAKER, gmake, gmake, make)
AC_PATH_PROG(GMAKE,gmake)
AS_IF([$MAKER --version | grep -q "GNU Make"],
[GNUMAKE="0"],
[AC_MSG_ERROR([It seems your system does not have make/gmake installed. If you are on Linux then install make, otherwise install gmake.])])
dnl Checks for libraries.
AC_CHECK_LIB(descrypt, crypt,
[AC_DEFINE([HAVE_CRYPT], [], [Define if you have crypt])
IRCDLIBS="$IRCDLIBS-ldescrypt "
MKPASSWDLIBS="-ldescrypt"],
IRCDLIBS="$IRCDLIBS-ldescrypt "],
[AC_CHECK_LIB(crypt, crypt,
[AC_DEFINE([HAVE_CRYPT], [], [Define if you have crypt])
IRCDLIBS="$IRCDLIBS-lcrypt "
MKPASSWDLIBS="-lcrypt"])])
AC_CHECK_LIB(socket, socket,
[IRCDLIBS="$IRCDLIBS-lsocket "
SOCKLIB="-lsocket"])
AC_CHECK_LIB(nsl, inet_ntoa,
[IRCDLIBS="$IRCDLIBS-lnsl "
INETLIB="-lnsl"])
AC_CHECK_LIB(crypto, RAND_egd,
AC_DEFINE(HAVE_RAND_EGD, 1, [Define if the libcrypto has RAND_egd]))
IRCDLIBS="$IRCDLIBS-lcrypt "])])
AC_SUBST(IRCDLIBS)
AC_SUBST(MKPASSWDLIBS)
dnl Check for big-endian system, even though these hardly exist anymore...
AS_CASE([$host_cpu],
[i?86|amd64|x86_64],
[ac_cv_c_bigendian=no]
)
AC_C_BIGENDIAN(
AC_DEFINE(NATIVE_BIG_ENDIAN, 1, [machine is bigendian]),
AC_DEFINE(NATIVE_LITTLE_ENDIAN, 1, [machine is littleendian]),
AC_MSG_ERROR([unknown endianness]),
AC_MSG_ERROR([universal endianness is not supported - compile separately and use lipo(1)])
)
dnl HARDENING START
dnl This is taken from https://github.com/kmcallister/autoharden
@@ -165,13 +111,9 @@ LD="$flag_wrap $LD"
# We use the same hardening flags for C and C++. We must check that each flag
[AC_DEFINE([NO_OPEROVERRIDE], [], [Define if you want OperOverride disabled])])])
AC_ARG_WITH(disableusermod, [AS_HELP_STRING([--with-disableusermod], [Disable /set* and /chg*])],
[AS_IF([test $withval = "yes"],
[AC_DEFINE([DISABLE_USERMOD], [], [Define if you want to disable /set* and /chg*])])])
AC_ARG_WITH(operoverride-verify, [AS_HELP_STRING([--with-operoverride-verify], [Require opers to invite themselves to +s/+p channels])],
[AS_IF([test $withval = "yes"],
[AC_DEFINE([OPEROVERRIDE_VERIFY], [], [Define if you want opers to have to use /invite to join +s/+p channels])])])
AC_ARG_WITH(disable-extendedban-stacking, [AS_HELP_STRING([--with-disable-extendedban-stacking], [Disable extended ban stacking])],
[AS_IF([test $withval = "yes"],
[AC_DEFINE([DISABLE_STACKED_EXTBANS], [], [Define to disable extended ban stacking (~q:~c:\#chan, etc)])])])
AC_ARG_WITH(system-tre, [AS_HELP_STRING([--with-system-tre], [Use the system tre package instead of bundled, discovered using pkg-config])], [], [with_system_tre=no])
AC_ARG_WITH(system-pcre2, [AS_HELP_STRING([--with-system-pcre2], [Use the system pcre2 package instead of bundled, discovered using pkg-config])], [], [with_system_pcre2=no])
AC_ARG_WITH(system-pcre2, [AS_HELP_STRING([--without-system-pcre2], [Use the system pcre2 package instead of bundled, discovered using pkg-config])], [], [with_system_pcre2=yes])
AC_ARG_WITH(system-argon2, [AS_HELP_STRING([--without-system-argon2], [Use bundled version instead of system argon2 library. Normally autodetected via pkg-config])], [], [with_system_argon2=yes])
AC_ARG_WITH(system-sodium, [AS_HELP_STRING([--without-system-sodium], [Use bundled version instead of system sodium library. Normally autodetected via pkg-config])], [], [with_system_sodium=yes])
AC_ARG_WITH(system-cares, [AS_HELP_STRING([--without-system-cares], [Use bundled version instead of system c-ares. Normally autodetected via pkg-config.])], [], [with_system_cares=yes])
CHECK_SSL
CHECK_SSL_CTX_SET1_CURVES_LIST
CHECK_SSL_CTX_SET_MIN_PROTO_VERSION
CHECK_SSL_CTX_SET_SECURITY_LEVEL
CHECK_ASN1_TIME_diff
CHECK_X509_get0_notAfter
AC_ARG_ENABLE(dynamic-linking, [AS_HELP_STRING([--disable-dynamic-linking], [Make the IRCd statically link with shared objects rather than dynamically (noone knows if disabling dynamic linking actually does anything or not)])],
<RuleSet Name="UnrealIRCd rules - based off Microsoft Native Minimum Rules" Description="These rules focus on the most critical problems in your native code, including potential security holes and application crashes. It is recommended to include this rule set in any custom rule set you create for your native projects." ToolsVersion="10.0">
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.