The way this union was accessed is not covered by the C++ standard and
was therefore undefined behavior. Therefore, the code was rewritten to
stick to standard C++.
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
Previously Mumble was using a custom binary format for transmitting data
via UDP (mainly audio). This has worked for a long time but besides
being inconvenient for 3rdParty implementors (they had to manually
re-implement encoding and decoding support for this format) this format
was not very flexible and changes to the data format were very hard.
In order to improve on this situation, this commit introduces changes
that allow to use Protobuf for the UDP messages as well (it's already
used for TCP). With that it should be relatively easy to extend/change
the UDP packet formats in the future and 3rdParty implementors can now
simply use Protobuf to handle decoding/encoding packets for them (much
less work and much less prone to errors).
Since the new Protobuf format is incompatible with the old UDP format,
this commit also includes support for dealing with older clients or
servers that don't recognize the new protocol yet. That way the new
protocol format is only used if both the client and the server are
recent enough to have it implemented (assumed to be the case >=1.5.0).
Note also that the server will make sure that clients using the old and
the new format can seamlessly communicate with one another.
Therefore, on the surface it should not be noticeable to the user which
protocol is currently used.
Note also that the new protocol format only supports Opus as an audio
codec. If one of the legacy codecs is to be used, the legacy packet
format has to be used as well. However, all codecs except for Opus will
be removed from Mumble in the future anyway.
Fixes#4350
Apparently the first commit (59ae429972)
did not include all files.
Furthermore the used script tended to produce funny results in certain
cases. This has been fixed and as a result thereof a few more changes
were made in this second run.
Qt 5.14 and higher
Qt 5.14 introduces a bunch of range-based constructors for the various
collection-classes that are now to be preferred over the generic
toList(), toSet(), toXY() functions
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."
Qt 5.6 changed QDBus to use a thread, QDBusConnectionManager,
for managing DBus connections.
This caused a bad interaction with Murmur. It turns out that, prior
to this commit, the QDBusConnectionManager in Murmur was launched at
program start, because of a global static QDBusConnection in DBus.cpp.
This meant that there would be a QDBusConnectionManager thread around,
waiting to manage DBus connections. ...Until Murmur calls fork().
After fork()ing, the QDBusConnectionManager thread is gone -- fork only
keeps a 'main' thread, and isn't generally compatible with multi-threaded
programs.
Ouch!
Fortunately, the static global QDBusConnection (MurmurDBus::qdbc) was
only initialized this way because it worked in the past. Also, because
QDBusConnection has no default constructor, the 'qdbc' QDBusConnection
was statically initialized as a QDBusConnection to 'mainbus' on each
program launch. This wasn't strictly necessary -- it was only done because
QDBusConnection had no default constructor. However, there is no such thing
as an 'empty' QDBusConnection, so there not being a default constructor
does make sense.
To avoid the static global QDBusConnection, this commit changes MurmuDBus::qdbc
from a value to a pointer.
This allows us to defer the creation of the QDBusConnectionManager thread
until the first 'real' QDBusConnection is created -- after Murmur has forked.
This avoids the global static 'fake' QDBusConnection, and ensures the
QDBusConnectionManager thread is created after Murmur has forked.
Additionally, this commit also moves the registration of the 'MetaDBus'
object into the '!Meta::mp.qsDBus.isEmpty()' check in main.cpp.
This ensures the MetaDBus object is only registered if the user has
enabled DBus in murmur.ini. Without this change, the code would be
dereferencing a null MurmurDBus::qdbc.
Fixesmumble-voip/mumble#2820
This method was broken by commit f260bd1913.
In particular, the line:
Channel *nc = server->addChannel(cChannel, name);
was removed by a locked block:
{
QWriteLocker wl(&server->qrwlVoiceThread);
server->addChannel(cChannel, name);
}
Note that nc is never assigned in the locked block.
See
f260bd1913 (diff-a6537e937b1df62a77d014d7a8c3008bL377)
for the full diff.
Fixesmumble-voip/mumble#2392
This gets rid of the following (harmless, but worrying) error in Murmur's log:
<W>2016-06-04 00:17:39.229 QObject::connect: No such slot MurmurDBus::userTextMessage(const User *, const TextMessage &)
I think there's a good excuse for this: we don't expose a user's password
hash over Ice, which is actually a pain in the backside for migrating
servers via Ice. So in the interests of consistency, I think it's probably
better to not expose the SSL private key or it's passphrase over Ice either,
particularly since SSL keys are a bit of a "cat out the bag" thing.
Note that at present, the SSL passphrase isn't exposed via meta either - the
"key" field of meta.GetDefaultConf() contains a plaintext copy of the key,
but I left the check in anyway in case we change that for any reason.
When the user specifically requests things that ought to be secret over Ice,
we raise an exception rather than have it silently fail, to hopefully reduce
the amount of head-scratching some poor script writer has to do.
Finally, more or less do the same thing over D-Bus.
Returning a list of groups using an authenticator added
temporary group membership for the user id only. Those are
removed when we're disconnecting an old user using the same
user id. Adding the session id to the group should fix the
problem.
This won't work if someone uses verifyPassword to set the
permissions (which is an undocumented implementation detail
anyway).
* uninitialized membervars,
* AudioOutput.cpp: fix delete on array to delete[]
* OSS.cpp: close file descriptor in false data case
* OverlayEditorScene.cpp: rm duplicate logic
* fix ifndef to match usage of declared variable
* member var initializations
* check for null (ds in d3d9 as some lines above),
* lower scope of var decl.,
* swap bufsize check and array dereference so check is before! deref,
* initialize member vars in constr.
