Commits
The first is that the verbose() call is made regardless of
whether the group ACL entity has the +c (GA_CHANACS) flag,
which is required to obtain channel privileges granted to
the group.
The second is that anyone can register a channel and add
any group to its ACL, and then set VERBOSE on that channel
in order to be notified of all flags changes to that group.
This commit addresses the second issue. Group administrators
who wish to preserve the privacy of its ACLs should set this
flag on, and use the GroupServ LISTCHANS command to review
which channels have an ACL entry for the group.
Reported-By: Klea <klea@iwnp.org>
The first is that the verbose() call is made regardless of
whether the group ACL entity has the +c (GA_CHANACS) flag,
which is required to obtain channel privileges granted to
the group.
The second is that anyone can register a channel and add
any group to its ACL, and then set VERBOSE on that channel
in order to be notified of all flags changes to that group.
This commit addresses the first issue.
It would be useful to have the option to log them when the
command is executed via an RPC request, so provide a function
that formats the prefix of log messages for commands executed
via RPC requests and have that function optionally include the
IP address if desired.
It would be useful to have the option to log them when the
command is executed via an RPC request, so provide a function
that formats the prefix of log messages for commands executed
via RPC requests and have that function optionally include the
IP address if desired.
Instead we can set the path while declaring the structure,
create a node and store its value for later use, and add the
structure to the list using that node. Then when mod_deinit()
is called we can just use the node we already created in order
to remove it from the list of handlers without iterating it.
This removes the ability to modify the XML-RPC handler path in
the HTTP server (an ability which was never documented, and
which the JSON-RPC module has never had), and brings the
module into line with the JSON-RPC module.
Instead we can set the path while declaring the structure,
create a node and store its value for later use, and add the
structure to the list using that node. Then when mod_deinit()
is called we can just use the node we already created in order
to remove it from the list of handlers without iterating it.
The previous code simply used the value of configuration parameter
`gameserv::max_rolls` if this could not be parsed as an integer, which
defaults to 10.
Correct the parsing code to return an error if the first parameter is
not a positive integer.
It does have the slight disadvantage that this would then immediately
call back into the crypto module it just used to encrypt it in order to
verify it, which would have twice the computational overhead. However,
this would be a one-time cost for a single login attempt; after that, it
would be encrypted already, and then it's the same computational cost as
any other login attempt.
Reported-By: glguy@libera.chat
- No encryption-capable crypto providers are loaded.
This is extremely negligent, but is still possible. Services complains
loudly every time it attempts to encrypt a password in this configuration,
but that will not stop some negligent sysadmins from ignoring these
messages and continuing to run it in this configuration.
- pbkdf2v2 is the only encryption-capable crypto provider loaded, it is
configured in SCRAM mode with GNU libidn for SASLprep normalisation, and
the user supplies a password containing invalid UTF-8 byte sequences or
ASCII control characters.
- Either argon2 or scrypt are the only encryption-capable crypto provider
loaded, and they are configured to use far more memory than the system has
available; high enough to cause libc to fall back to a direct mmap(2), and
high enough for the kernel's overcommit logic to reject it as extreme,
returning NULL.
This is because set_password() has no way to indicate to its caller whether
it was able to encrypt the password or not.
This commit forces set_password() to encrypt the password or return failure
to its caller. The callers now check whether it was successful and abort
their operation if it was not.
Also add a note to the SASL SCRAM documentation mentioning the prohibited
password characters, and the same to the help files for commands that take
passwords (but only if the SASL SCRAM module is loaded).
Cases where the account does not exist already return fault_nosuch_target.
This reverts commit a79f0eeebf7cf2ef6b61a5b96b15893019d208c7.
This being present prevents configuring chanserv::default_mlock to
not have an opinion one way or the other about whether these should be locked on or off.
The ubuntu-20.04 runner is going to be retired in April. The
checkout@v2 action has been superseded by the checkout@v4 action.
Fix various minor issues with the InspIRCd protocol module
This command is intended for use by clients not by servers.
transport/rfc1459: Skip IRCv3 message tags if they exist.
Fix parsing PONG messages from InspIRCd.
Fix parsing remote SERVER messages from InspIRCd.
The first is that the verbose() call is made regardless of
whether the group ACL entity has the +c (GA_CHANACS) flag,
which is required to obtain channel privileges granted to
the group.
The second is that anyone can register a channel and add
any group to its ACL, and then set VERBOSE on that channel
in order to be notified of all flags changes to that group.
This commit addresses the second issue. Group administrators
who wish to preserve the privacy of its ACLs should set this
flag on, and use the GroupServ LISTCHANS command to review
which channels have an ACL entry for the group.
Reported-By: Klea <klea@iwnp.org>
The first is that the verbose() call is made regardless of
whether the group ACL entity has the +c (GA_CHANACS) flag,
which is required to obtain channel privileges granted to
the group.
The second is that anyone can register a channel and add
any group to its ACL, and then set VERBOSE on that channel
in order to be notified of all flags changes to that group.
This commit addresses the first issue.
Instead we can set the path while declaring the structure,
create a node and store its value for later use, and add the
structure to the list using that node. Then when mod_deinit()
is called we can just use the node we already created in order
to remove it from the list of handlers without iterating it.
This removes the ability to modify the XML-RPC handler path in
the HTTP server (an ability which was never documented, and
which the JSON-RPC module has never had), and brings the
module into line with the JSON-RPC module.
Instead we can set the path while declaring the structure,
create a node and store its value for later use, and add the
structure to the list using that node. Then when mod_deinit()
is called we can just use the node we already created in order
to remove it from the list of handlers without iterating it.
It does have the slight disadvantage that this would then immediately
call back into the crypto module it just used to encrypt it in order to
verify it, which would have twice the computational overhead. However,
this would be a one-time cost for a single login attempt; after that, it
would be encrypted already, and then it's the same computational cost as
any other login attempt.
Reported-By: glguy@libera.chat
- No encryption-capable crypto providers are loaded.
This is extremely negligent, but is still possible. Services complains
loudly every time it attempts to encrypt a password in this configuration,
but that will not stop some negligent sysadmins from ignoring these
messages and continuing to run it in this configuration.
- pbkdf2v2 is the only encryption-capable crypto provider loaded, it is
configured in SCRAM mode with GNU libidn for SASLprep normalisation, and
the user supplies a password containing invalid UTF-8 byte sequences or
ASCII control characters.
- Either argon2 or scrypt are the only encryption-capable crypto provider
loaded, and they are configured to use far more memory than the system has
available; high enough to cause libc to fall back to a direct mmap(2), and
high enough for the kernel's overcommit logic to reject it as extreme,
returning NULL.
This is because set_password() has no way to indicate to its caller whether
it was able to encrypt the password or not.
This commit forces set_password() to encrypt the password or return failure
to its caller. The callers now check whether it was successful and abort
their operation if it was not.
Also add a note to the SASL SCRAM documentation mentioning the prohibited
password characters, and the same to the help files for commands that take
passwords (but only if the SASL SCRAM module is loaded).