against HTTP POST proxies, now added some extra text to say it also
protects against the Firefox XPS IRC Attack. Also made NOSPOOF enabled by
default on *NIX (this was already the case on Windows).
- Updated ./Config description for DPATH. Seems quite some people answer
this question wrong, and when that happens, you only get some obscure
error when running './unreal start'.
- Fixed 'unreal' script to give a better error if it cannot find the IRCd
binary.
Previously this caused some really odd behavior. Backslashes are now
treated as-is, so no special escaping is necessary. Reported by DelGurth
(#0003002).
- Removed old dgets() function
redundant and confusing. Also removed an old statement saying k-lines would
be erased on rehash which is not true. Documented '/rehash -dns'.
Reported by ohnobinki (#0003881).
curl detection, added checks to see if curl actually works (print out a
clear curl error during configure, instead of getting an error during
'make'), and we now error when using --enable-libcurl without
--with-system-cares if the system curl depends on c-ares. This is because
this can cause ABI incompatability between curl's c-ares and our c-ares,
which leads to odd issues such as:
Could not resolve host: www.example.net (Successful completion)
And possibly other weird issues, perhaps even crashes.
it to 'no', the default is 'yes' (on). Requested by Robin (#0003885) as
UHNAMES may increase the time of the nick list being loaded from 1 to 4
seconds when joining several channels with more than 1000 users. As this
problem is only present on some networks, we keep UHNAMES enabled by
default.
descriptors. Because of this, Unreal did not restart properly as you would
get an "Address already in use" error. This only seemed to happen when
logging to syslog, or when there was something wrong with syslogd.
Reported by Mouse (#0003882).
descriptors. Because of this, Unreal did not restart properly as you would
get an "Address already in use" error. This only seemed to happen when
logging to syslog.
- Fixed a similar issue with syslog (and debugmode) and closing fd's as well:
the first port we listened on would not open up, ircd did not log any error.
- Made ./Config description about remote includes a bit more clear.
- When you now answer Yes to Remote includes in ./Config and $HOME/curl does
not exist, it now asks you if you want to automatically download and
install curl (which is done by ./curlinstall).
This has been tested on Linux, further testing on f.e. FreeBSD is
required.
- Server protocol: added PROTOCTL EATH=servername, which allows us to
authenticate the server very early in the handshake process. That way,
certain commands and PROTOCTL tokens can 'trust' the server.
See doc/technical/protoctl.txt for details.
- Server protocol: between new Unreal servers we now do the handshake a
little bit different, so it waits with sending the SERVER command until
the first PROTOCTL is received. Needed for next.
- Server protocol: added PROTOCTL SERVERS=1,2,3,4,etc by which a server can
inform the other server which servers (server numeric, actually) it has
linked. See doc/technical/protoctl.txt and next for details.
- When our server was trying to link to some server, and at the same time
another server was also trying to link with us, this would lead to a
server collision: the server would link (twice) ok at first, but then a
second later or so both would quit with 'Server Exists' with quite some
mess as a result. This isn't unique to Unreal, btw.
This happened more often when you had a low connfreq in your link blocks
(aka: quick reconnects), or had multiple hubs on autoconnect (with same
connfreq), or when you (re)started all servers at the same time.
This should now be solved by a new server handshake design, which detects
this race condition and solves it by closing one of the two (or more)
connections to avoid the issue.
This also means that it should now be safe to have multiple hubs with low
connfreq's (eg: 10s) without risking that your network falls apart.
This new server handshake (protocol updates, etc) was actually quite some
work, especially for something that only happened sporadically. I felt it
was needed though, because (re)linking stability is extremely important.
This new feature/design/fix requires extensive testing.
This feature can be disabled by: set { new-linking-protocol 0; };
having to use a special SSL-only port, they can simply switch to SSL on
any port. This is currently only supported by few clients (such as KVIrc 4).
This functionality can be disabled by setting set::ssl::options::no-starttls,
for example if you don't want to offer SSL to your users and only want it
to be used for server to server links.
Naturally, the IRCd must be compiled with SSL support for STARTTLS to work.
- Fixed SSL_ERROR_WANT_READ in IRCd_ssl_write()
such as ~q:~c:#test to only silence users on #test, for example. This feature
is enabled by default, but can be disabled during ./Config -advanced. Module
support for this feature must note the following:
- For is_ok function, the extban can either assign extban_is_ok_nuh_extban, which
will deal checking a chained extban (including checking for restricted extbans),
or it can call that function from its own is_ok routine. For the latter case,
remember to pass only the mask part of your ban format (ie, don't just pass para as
otherwise it'll just call your is_ok again).
- For conv_param function, the extban can either assign extban_conv_param_nuh_or_extban,
which will automatically call conv_param for a chained extban, or pretty up a n!u@h mask.
- For is_banned, the extban should call ban_check_mask with the mask part of the parameter.
This will automatically call is_banned for a stacked extban, or match against a n!u@h. n!u@h
is checked against the current user (ie, with the info in the globals ban_ip, etc), so things
can get weird if you call this outside a normal ban check.
Modules must keep in mind that chained extban support is not available (and neither are the three
functions above) if DISABLE_STACKED_EXTBANS is #defined (this is controled by Config). Modules will
not compile/load if they try to use them anyway.
This change should not break extban modules, and should need some more extensive testing.
- Misc fix for disabling extban chains, should've done stuff in our autoconf
stuff instead of hacking configure directly :P .
autoupdate