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.
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
* 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 ;)
to validate the certificate of the link, making sure that:
1) The certificate is issued by a trusted Certificate Authority (CA).
2) The name on the certificate matches the name of the link block.
Some things still need to be done: documentation, more testing, and
using the X509_check_host() function when available.
Nobody used this option and it only caused the following confusing
(and potentially insecure) behavior:
Previously if you had 'verify-certificate' enabled then the certificate
would be checked, BUT if it was a self-signed certificate (and thus
not passing verify-cert) it was STILL allowed unless you also
specified the 'no-self-signed' option. This might be correct as per
documentation but is way too confusing for the user.
Now you simply have to choose whether you verify the certificate or
not. No special handling for self-signed certificates.
This allows you to for example specify a specific certificate/key on an
serversonly port and in link block (a self-signed 10 year valid certificate)
and use a short-lived (XX day) Let's Encrypt certificate on the other ports.
And several other uses, of course.
* remove netadmin, services-admin, admin, co-admin.
* remove all oper flags (there are some placeholders for the next... <24hrs..)
* ADMINCHAT and NACHAT are gone, since admin & netadmin no longer exist
* SVSO used oper flags, but this no longer exists, SVSO removed. maybe later we can add some sort of replacement.. maybe..
* re-style the m_oper code a bit
Coders: added generic mask functions: unreal_mask_match(), unreal_add_masks() and unreal_delete_masks().
These deal with one or multiple masks and do all the work for you ;)
Bram Matthys