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 ;)
Still requires module and core hooks to be added, config test to be added, and to require these for perm validation - this enables core parser and querying of system though
* add general matching framework (aMatch type, unreal_match_xxx functions)
* change spamfilter { } block syntax
* add support for simple wildcard matching (non-regex, just '?' and '*')
This is the initial commit so the new lib is not in yet, 'regex' is not
functional (but 'posix' and 'simple' are working), linking has not been
fully tested and no warnings are printed yet. IOTW: work in progress!
you want to permit re-loading but not complete un-loading of your module.
This way you get the benefits of being able to upgrade code on-the-fly but
can still disallow the user to do something potentially unwise.
For services who allow you to log in by account name but still allow you to
use a different nick: when you're logged in you are now considered
registered as far as channel mode +M (only registered users may speak and
+R (only registered users may join) are concerned. Same for user mode +R
(only allow private messages from registered users).
Tech: whenever services set SVID and it's not * and does not start with a
number, then we consider this user to be 'logged in'.
Whenever a user is set +r (s)he is also considered 'logged in'.
This way it's compatible with both older and new services and doesn't
introduce security issues with older services using servicetimestamp
for nick tracking or other means.
This issue was reported by ShawnSmith (#4318).
Now you can just add password "$ZaJw56to$uSEc[etc..]"; to your configuration file without needing an explicit { md5; }; or { sha1; };.
Naturally you can still specify an auth-type if you want to, and for types like 'sslclientcert' it's still required.
We no longer support builds without OpenSSL - consequently we have no reason to keep our custom MD5 implementation, and probably shouldn't keep it around
Bram Matthys