With the old qmake buildsystem we used to set QT_NO_CAST_FROM_ASCII (for
the Mumble client) in order to avoid problems with character encodings
in our Strings. This was not done in the new cmake system yet.
Instead of the aforementioned macro, this commit sets (for all targets)
QT_RESTRICTED_CAST_FROM_ASCII instead in order to be able to
automatically convert direct String literals to QString as these usually
don't contain any problematic characters (non-ASCII) in the first place.
And this allows to e.g. compare a QString against a String literal or do
something like
QString myString = "This is a test";
which we know to be unproblematic.
Note however that (quote from Qt's docs)
"Using this macro together with source strings outside the 7-bit range,
non-literals, or literals with embedded NUL characters is undefined."
This option allows to set a threshold on how long a user's channel
should be remembered. This is useful for scenarios where users usually
don't want their channel to be remembered by the server unless they had
a disconnect (aka have ot re-connect after a short period of time).
Implements #4143
This option allows to set a threshold on how long a user's channel
should be remembered. This is useful for scenarios where users usually
don't want their channel to be remembered by the server unless they had
a disconnect (aka have ot re-connect after a short period of time).
Implements #4143
qrand() has been deprecated in Qt 5.15. Therefore this commit replaces
it with QRandomNumberGenerator as recommended by Qt.
As the RNG returned by QRandomNumberGenerator::global() (which was used
throughout this refactoring) is already seeded (according to the docs),
there is no need to explicitly seed the RNG in the main function as has
been done before by calling qsrand().
Qt 5.14 has introduced Qt::SplitBehavior which now holds the flag that
were previously contained in the QString class. The fields still exist
in QString but they are deprecated since Qt 5.15.
The idea here is that sometimes you really do have a lot of folks connecting from a single IP,
and if those connections are successful you don't want to ban any of them.
However, in cases where the server needs to guard against malicious users attempting a DDOS
by reconnecting their valid user account over and over, we need to be able to configure the
server to still ban those successful attempts.
This implements #3319 by allowing users to "listen" to a channel they
have not joined. Doing so will place a "listener proxy" (in other
software this is sometimes known as a "phantom") in that channel which
will look like a normal user except that it'll have the same name as the
user listening to that channel and an ear-icon instead of the normal
avatar-icon. It will also always show a muted-icon next to it.
If a listener proxy is in a channel, the server will route all audio
packets from that channel to the user the proxy belongs to (as if that
user was in the channel). Note though that the opposite of this is not
true: The users in the channel will not hear audio from the listening
user unless that user decides to join the channel.
Furthermore it is possible to set a local volume adjustment for each
individual proxy that will be applied to all audio that is received
through it.
As requested in #2481, this commit introduces the option to print
changes of ACLs and/or groups to the server-log. These logs then contain
the ALCs/groups before the change and after it and should thereby grant
all information necessary to debug what is going on with them.
This adds client authentication using TLS certificates when it is
enabled in gRPC. This just the basic feature right now. You either have
access or you do not.
Access is granted by putting the certificate digests of the authorized
users into the murmur.ini file.
This commit adds all the missing includes when the PCH header is not used.
Also, some includes are reordered and/or made consistent (e.g. "#include <QtEndian>" -> "#include <QtCore/QtEndian>").
According to Qt's documentation the PCH header doesn't need to be included.
From https://doc.qt.io/qt-5/qmake-precompiledheaders.html:
"To make your project use precompiled headers, you only need to define the PRECOMPILED_HEADER variable in your project file."
"qmake will handle the rest, to ensure the creation and use of the precompiled header file. You do not need to include the precompiled header file in HEADERS, as qmake will do this if the configuration supports precompiled headers."
This adds messagelimit and messageburst to the configuration file murmur.ini as
well as the ability to set these live.
Though adjusting these live is entirely possible, they only take effect for new connections.
Having to many channels on a server can impact performance to the point
of making the instance unusably slow. This can be a problem for hosters
that allow their users unlimited channel creation.
This patch introduces a new per-server configuration parameter
channelcountlimit which can be used to configure a maximum number of
channels that may be created on each of the virtual servers. Once the
limit is reached channel creation will be rejected with permission
denied.
To allow a translated error message we have to bump the client version
to 1.3.1 to be able to use a fallback message for older clients.
As usual dbus, ice and grpc can ignore this limit. It is only enforced
against clients.
The QSslDiffieHellmanParameters class is only available in Qt 5.8 or
greater. (And in our buildenv's Qt 5.6 as well.)
When using Qt 4, or Qt 5 below 5.8, Murmur should refuse to run if
sslDHParams is set in the .ini.
However, with the introduction of the "@ffdhe2048" default value,
this mechanism broke: since the default value is not empty, users
of a Qt without QSslDiffieHellmanParameters would not be able to run
Murmur unless the explicitly set sslDHParams to the empty string.
This commit fixes the problem by comparing against the value from the
.ini, instead of potentially also checking against the default value.
This commit uses the new FFDHE::NamedGroups() method to improve the error
message Murmur shows when sslDHParams is set to an unknown "bundled"
group, i.e. a name that starts with @, such as @ffdhe2048.
Using SQLite's WAL (write-ahead log) can create less disk I/O while
still providing good consistency and durability.
This change uses SQLite's WAL with synchronous=NORMAL which can
cause loss of transactions on power failure. Only the transactions
which haven't been synced to the disk by the OS are lost. The
database itself will still be in a consistent state, but it might
not have all recent changes.
On systems using systemd, Murmur is often started early, even before
Murmur can query the network interfaces.
This commit adds a fallback, where Murmur will expect such a system to
support both IPv4 and IPv6.
Fixesmumble-voip/mumble#1629Fixesmumble-voip/mumble#1904
This moves the SSL loading code from MetaParams::read() into a separate
method, loadSSLSettings(). It also hooks up the SIGUSR1 signal handler
to reload SSL settings and apply the setings to each suitable virtual
server.
A follow-up commit will change MetaParams::read() to also use loadSSLSettings(),
however it was left out of this commit to aid in reviewability.
This change moves the QSslSocket::supportsSsl() check from MetaParams:read()
to main.cpp. This also ensures that the SSL check happens very early in Murmur's
initialization process, rather than after we might have already attempted to
call some SSL-related APIs.
This change also moves the log message that prints the OpenSSL version to main.cpp,
and integrates it with the QSslSocket::supportsSsl() check.
In order to reload the SSL settings live, we need to know the .ini file
Murmur used when initially loading its settings, in order to re-load the
settings from the same file.
This moves the qmConfig.clear() call in MetaParams::read() to the
top of the function.
This allows the SSL part of MetaParams::read() to be moved out to a
separate function in the upcoming PR for live-reloading SSL settings
via the SIGUSR1 signal.
This allows the setting to be loaded from an arbitrary QSettings instance.
We need this to be able to implement live reloading of SSL settings via the SIGUSR1 signal.
Before this commit, we would add any intermediate certificates found in
the SSL certificate's PEM bundle to the default CA list via
QSslSocket::addDefaultCaCertificates().
We would also add any certificates found in the sslCA PEM bundle to the
default CA list, using the same method.
Due to the way the hot-reload feature for SSL settings is going to work,
these patterns wouldn't work well in that environment, because reloading
the settings would keep adding entries to the global QSslSocket default
CA certificates list. (QSslSocket::defaultCaCertificates())
To combat this, this series of commits try to be more strict about how
default CAs and intermediates in general are handled.
Generally, instead of adding them to the global QSslSocket default CA
list, we add them to each QSslSocket as necessary.
Note: this commit does not stand on its own. It requires the follow-up
commits in this PR. It is split out to aid in reviewing.
