In a Qt application, the QApplication object should be the first QObject
that is created. However, the `Meta` class used to have a static member
called `mp`, which means that this member gets initialized _before_
main() runs and therefore before the QApplication is created.
This has caused an "Invalid nullptr in QObject::connect" warning
somewhere in Qt's internals (since the move to Qt 6). The impact of this
warning is unclear at this point.
This commit makes the mp parameter a std::unique_ptr that gets
explicitly initialized in the main function (more or less right after
the QApplication object is created). This guarantees that the MetaParams
object does not get created before the QApplication object, fixing the
observed warning.
It is worth noting that we do have a couple of other static QObject
variables in the main translation unit, but these seem to be
inconsequential (at least they don't seem to trigger a similar warning).
Fixes#6669
The DBus RPC interface on the server has been deprecated for a while and
has also not been maintained for even longer. Therefore, the API has now
been removed completely.
Instead, users shall make use of the ZeroC Ice interface as a means to
do RPC.
Fixes#6548
In various places we relied on compiler extensions such as
variable-length arrays on the stack or using non-standard escape
sequences. In order to make our code as portable as possible, these
parts of the code have been refactored to only use standard C++.
Furthermore, the new warning settings triggered a bunch of new warnings
all over the place that have been addressed by this commit.
Apparently, QSettings does not care if the specified settings file exists or not.
Therefore, no keys will be loaded into the settings as if the file was empty.
We specifically check for the missing file to not reference a ghost file in the logs.
Fixes#6077
For registered users, the server will now remember their channel
listeners (and their volume adjustments) and will restore them once the
user rejoins this server.
Previously the server was only looking for files named e.g. murmur.ini
or murmur.sqlite. With this commit, the server will now look first for
files called mumble_server.ini and mumble_server.sqlite before falling
back to the old names (for backwards compatibility).
This is meant as a means to drive forward the server renaming from
murmur(d) to mumble-server.
Previously, the Mumble version was encoded with a uint32
in the network protocol reserving 2 bytes for the major
component and 1 byte for each minor and patch.
The versioning format was changed to include a build
number in the patch field. With a recent update (1.4.274)
the patch field exceeded 255 for the first time and broke
the protocol version.
This commit completely reworks how the version is stored
internally and transfered with the network protocol.
The new version is a uint64 and consists of 4 fields with
2 bytes each. This allows each version component to reach
up to 65535. Furthermore, all instances of integer version
types have been replaced with the alias Version::full_t for
a better abstraction. Version literals have been replaced by
Version::fromComponents calls.
Fixes#5827
In theory these changes should cause the server to no longer silently
ignore encountered INI syntax errors.
In practice however, it seems that it is pretty much impossible to
create an INI file that Qt actually considers erroneous and thus this
code essentially doesn't work. But in case Qt ever fixes this weird
behavior, at least in theory Mumble users should immediately profit from
it.
Fixes#5749
Previously the opusthreshold config option had a default value of 100
meaning that the first non-Opus client would cause everyone to fall back
to one of the legacy codecs.
Since Opus has been implemented for ages now and we eventually want to
get rid of the legacy codecs, this commit changes the default value of
this config option to be zero, meaning that the server will always
enforce the use of the Opus codec (regardless of what clients are
connected).
The gRPC implementation never left the experimental state and never
reached a properly stable state to the point where we would feel good
about enabling it by default. In addition to that, there has been no
further attempts at finding and fixing the encountered issues in the
implementation (except #3947 but that was discontinued).
As such we had an essentially unmaintained piece of code in our server
implementation that was known to be buggy and that nobody wanted to fix.
In addition to that the implementation itself could not be considered
very clean or elegant and therefore only represented a few smelly
corners in our code base.
For this reason, we decided to remove the gRPC support entirely from
Mumble (for now).
What we hope to gain by that is:
- Prevent people from building unstable server versions and then coming
to us complaining that it crashed/misbehaved
- Removing (essentially) dead code
- Reduce the RPC implementation complexity
That last piece is crucial: By removing gRPC support we reduce the
amount of supported RPC frameworks to only one (ignoring DBus for now).
Our future plans include a refactoring of how RPC is being handled and
implemented and only having to worry about maintaining compatibility
with one RPC system is much easier than having to worry about two (with
(slightly) different APIs).
Once the RPC implementation has been rewritten, more RPC backends may be
reintroduced and in that process we might investigate adding a proper
gRPC implementation to the code (that then hopefully is more stable than
the current one).
Fixes#4567Fixes#4197Fixes#3496Fixes#3429Fixes#3265
This commit adds a new server-configuration that can be used in the
murmur.ini file. It can be used to forbid anyone on the server from
using Mumble's built-in recording functionality.
Any client trying to start a recording nonetheless, will be kicked from
the server.
From Mumble 1.5.0 clients will know about this configuration and will
disable the recording action in the UI, if recording is not allowed on
the server.
The check for configured network interfaces at startup has a problem
that if IPv4 is not configured for some reason, Mumble will bind to
IPv6-only socket, and will not be available over IPv4 until manually
restarted.
There's no harm binding to the "any" IPv6 address with IPV6_V6ONLY set
to 0 even if there're no assigned addresses of either address family.
The bind will succeed either way, and will accept connections on any
new address configured in the system regardless of the address family.
QHostAddress::Any tries to setup an AF_INET6 socket with IPV6_V6ONLY
set to 0, and falls back to AF_INET in case it's unavailable.
However, it will only happen if IPv6 is completely disabled on the
system, which is a rare configuration, but nevertheless it will fall
back gracefully.
Fixes#5208
This commit introduces a new plugin framework into the codebase of the
Mumble client. Note that "plugin" here really refers to a (more or less)
general purpose plugin and is therefore not to be confused with the
previously available positional data plugins (only responsible for
fetching positional data from a running game and passing that to
Mumble).
The plugin interface is written in C, removing the compiler-dependence
the old "plugins" had. Instead plugins can now be written in an
arbitrary language as long as that language is capable of being compiled
into a shared library and also being capable of being C-compatible.
As already indicated a plugin is essentially a shared library that
provides certain functions that allow Mumble to interface with it.
Inside Mumble the so-called PluginManager is responsible for managing
the plugins and relaying events to the respective callbacks. Plugins
themselves can also interact with Mumble on their own initiative by
using the provided API functions.
Fixes#2455Fixes#2148Fixes#1594Fixes#2051Fixes#3742Fixes#4575Fixes#4751
The default RegEx for describing valid usernames was updated to also
allow for spaces in names.
Note that "empty" names (e.g. names only consisting of whitespace) are
not possible since usernames are always trimmed before being applied and
the RegEx does not allow for names of length 0.
Fixes#1202
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.
