1a4d134a35 introduced the ability to
disable TTS for specific users. The change however didn't account for
messages that are sent from the server. In these cases pSrc is nullptr
but that commit introduced code that access it without checking for
null. This lead to a SegFault as soon as a text message from the server
is received.
This commit fixes this by simply adding a null-check before accessing
the variable.
Before this PR, if the MainWindow was set to be always on top of
other windows, it could happen that the UserLocalVolumeDialog got hidden
behind the MainWindow (it wanted to open on top of it but since the
MainWindow is set to be on top of all other windows, it couldn't). This
could be especially annoying on Windows where you can't move the
MainWindow away as long as the UserLocalVolumeDialog is open (luckily
you can close it via Esc though).
In order to avoid this kind of situation, this commit make the
UserLocalVolumeDialog "inherit" the AlwaysOnTop flag from the
MainWindow. This way it can open on top of it again and won't be hidden.
These changes make it possible to disable Text-To-Speech for specific
users while still receiving the messages as normal text.
A use case for this would be muting text to speech for a music bot.
These changes make it possible to turn of TTS for a specific user while
still receiving their messages.
This setting can be managed from the context menu of a user that is
connected to the server and is only visible when TTS is enabled
globally.
A new DB table called 'ignored_tts' had to be created to persist this
setting.
This fixes a regression introduced in
b691108. In there it was thought that
there is no need to explicitly add the system CaCertificates to the SSL
configuration. This turned out to be wrong.
It was brought up that by removing this line, properly signed
certificates would also be shown as self-signed.
Fixes#4289
This fixes a regression introduced in
b691108d38. In there it was thought that
there is no need to explicitly add the system CaCertificates to the SSL
configuration. This turned out to be wrong.
It was brought up that by removing this line, properly signed
certificates would also be shown as self-signed.
Fixes#4289
Implements functionality to send an image by copy and paste into the chat bar of mumble.
This is a commonly expected behavior of any chat app. Can't see why mumble should not have one.
Furthermore it also implements Drag&Drop for images to the chatbar.
The initialization code is now moved into its own function (instead of
also living inside the setActive function body). This is done in order
to better separate initialization and activation.
In the old implementation the overlay was initialized as soon as
Overlay::setActive got called regardless of whether it was asked to
actually activate.
This commit makes sure to only initialize the Overlay if it is actually
asked to be activated via Overlay::setActive(true).
In aac3214d4b Overlay::createPipe() has
been introduced in order to only create the pipe when needed (instead of
in the constructor of the Overlay class). This new function was never
called though which caused the Overlay to stop working.
This commit makes sure the respective function is called when activating
the overlay.
Fixes#4281
Previously the certificates were added to the QSslSocket object directly
but Qt 5.15 added this functionality to the QSslConfiguration object and
deprecated the ones in QSslSocket.
Previously AppImages built on the CI got their updates from https://dl.mumble.info/snapshots/
but now we have a separate directors `nightly` that'll contain CI build artifacts and this should be used instead.
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 function in question has been deprecated in Qt 5.15. Instead it is
recommended to set the CA certificates on the QSslConfiguration object.
According to the docs of QSslConfiguration however the system's CA
certificates is what is used by default anyways.
Quote (from 5.15 docs of QSslConfiguration::systemCaCertificates):
"This function provides the CA certificate database provided by the
operating system. The CA certificate database returned by this function
is used to initialize the database returned by caCertificates() on the
default QSslConfiguration."
Some labels were stacked on top of each other in the Positional Audio
section of the settings page. This probably happened in a wrongly
resolved merge-conflict and is corrected by this commit.
The check was originally implemented to avoid initializing multiple channels when it was guaranteed only one would be available (i.e. positional audio disabled).
Now that we support stereo audio decoding (#4209), the check has to be removed in order to make the feature available when positional audio is disabled.
The check was originally implemented to avoid initializing multiple channels when it was guaranteed only one would be available (i.e. positional audio disabled).
Now that we support stereo audio decoding, the check has to be removed in order to make the feature available when positional audio is disabled.
When a client disconnected from the server that was still talking and
therefore showing up in the TalkingUI, it could happen that this user
was not removed from it even though it was no longer on the server. This
is due to a race-condition in the event chain: It could happen that the
respective user object got deleted before the on_talkingStateChanged
function in the TalkingUI got called. This then led to this function not
getting a reference to the user object which causes it to return.
This commit explicitly wires up the UserRemove event with the TalkingUI
to make sure a user gets removed from it once it is removed from the
server.
When a client disconnected from the server that was still talking and
therefore showing up in the TalkingUI, it could happen that this user
was not removed from it even though it was no longer on the server. This
is due to a race-condition in the event chain: It could happen that the
respective user object got deleted before the on_talkingStateChanged
function in the TalkingUI got called. This then led to this function not
getting a reference to the user object which causes it to return.
This commit explicitly wires up the UserRemove event with the TalkingUI
to make sure a user gets removed from it once it is removed from the
server.
This is an attempt to provide a unified interface for all crypto classes, in order to support multiple ciphers and the crypto negotiation mentioned in #3918 in the future.
That being said, I have to readdress the sad fact that I'm not a C++ expert and have no previous experience of developing a huge project like mumble, hence I'm not very sure about all my moves, whether I'm using the best practice or not. I sincerely hope you guys may provide some insights and suggestions and I would be surely grateful for that.
As explained in https://github.com/mumble-voip/mumble/issues/4219#issuecomment-636218461:
In simple terms:
Never encrypt any message where the second to last block starts (or ends? don't recall how len was actually implemented in OCB2. be sure not to mess this one up! if unsure, just do both) with 120 bits of zeros.
Ignore any decrypted message which we would not have encrypted according to 1.
Given we mostly send compressed audio over UDP, it seems unlikely that there would ever legitimately be 120 bits of zeros, so impact should be minimal. Ping packets are probably only a single block in size, so they're not affected either.
Removing either encryption or decryption oracle will make the attacks impossible. And because a Mumble client never decrypts its own packets, if we take away both on the server, even un-patched clients should be safe (as long as they're connected to a patched server) and vice-versa (though ofc the other way around all the participating clients would have to be patched if the server isn't since any one of them could leak the full conversation).
The respective paper can be found at https://eprint.iacr.org/2019/311
Special characters inside of markdown code in the chat were escaped twice.
The message **<test>** was previously escaped to **<test>**.
The markdown code changed the ** to <b> tags,
but also escaped the & character again, resulting
in <b>&lt;test&gt;</b>.
Due to the double escaping, special characters like < were not
displayed correctly.
Fixes: #4179
Special characters inside of markdown code in the chat were escaped twice.
The message **<test>** was previously escaped to "**<test>**".
The markdown code changed the "**" to "<b>" tags,
but also escaped the "&" character again, resulting
in "<b>&lt;test&gt;</b>".
Due to the double escaping, special characters like "<" were not
displayed correctly.
Fixes: #4179
Co-authored-by: Fabian Muentefering <fabian.muentefering@stud.uni-hannover.de>
OCB2 is known to be broken under certain conditions:
https://eprint.iacr.org/2019/311
To execute the universal attacks described in the paper, an attacker needs
access to an encryption oracle that allows it to perform encryption queries with
attacker-chosen nonce. Luckily in Mumble the encryption nonce is a fixed counter
which is far too restrictive for the universal attacks to be feasible against
Mumble.
The basic attacks do not require an attacker-chosen nonce and as such are more
applicable to Mumble. They are however of limited use and do require an en- and
a decryption oracle which Mumble seemingly does not provide at the same time.
To be on the safe side, this commit implements the counter-cryptanalysis
measure described in the paper in section 9 for the sender and receiver side.
This way if either server of client are patched, their communication is almost
certainly (merely lacking formal proof) not susceptible to the attacks described
in the paper.
In #3803 it is reported that the server regularly crashes because the
MySQL/SQLite part of the database code for group changes doesn't handle
conflicts in primary keys (as the PostgreSQL part does).
This commit makes the SQL statement use REPLACE INTO instead of INSERT
INTO which according to the docs "REPLACE works exactly like INSERT,
except that if an old row in the table has the same value as a new row
for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the
new row is inserted."
It's actually a MySQL extension but according to Wikipedia SQLite
supports it as well.
Before this commit we had 3 places in the AudioOutput settings page that
dealt with stuff related to attenuation (1 in the "Audio Output"
section, the "Advanced Attenuation Options" and the "Priority Speaker"
section).
This PR merges all of them into a single "Attenuation" section.
