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).
1) No arguments: UnrealIRCd will prompt you to enter a password and hash
it with the bcrypt algorithm. This is the recommended method.
2) One argument: It will hash the provided password with bcrypt
3) Two arguments: It will use the hashing algorithm of your choice (1st arg)
to hash the provided password (2nd arg)
We recommend to use syntax #1 as bcrypt is the best algorithm available and
by using the prompt the password won't end up in your bash history (or
whatever shell you use) and can't be snooped by other people with a shell
on the same machine (by looking at the process list)
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.
Travis McArthur