Comparing changes
Open a pull request
base repository: mumble-voip/mumble
base: 1.3.3
head repository: mumble-voip/mumble
compare: 1.3.4
- 10 commits
- 23 files changed
- 5 contributors
Commits on Feb 6, 2021
-
src/murmur/main.cpp: Use qInfo instead of qFatal for normal logging.
-
FIX(client): Ancient notification icon names
These no longer exist in contemporary icon themes like Adwaita. Per https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html and https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html
-
Merge pull request #4737: Backport "FIX(client): Ancient notification…
… icon names" These no longer exist in contemporary icon themes like Adwaita. Per https://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html and https://specifications.freedesktop.org/icon-naming-spec/latest/ar01s04.html This is a backport of #4705
-
FIX(client): Only allow "http"/"https" for URLs in ConnectDialog
Our public server list registration script doesn't have an URL scheme whitelist for the website field. Turns out a malicious server can register itself with a dangerous URL in an attempt to attack a user's machine. User interaction is required, as the URL has to be opened by right-clicking on the server entry and clicking on "Open Webpage". This commit introduces a client-side whitelist, which only allows "http" and "https" schemes. We will also implement it in our public list. In future we should probably add a warning QMessageBox informing the user that there's no guarantee the URL is safe (regardless of the scheme). Thanks a lot to https://positive.security for reporting the RCE vulnerability to us privately.
-
TRANSLATION: Update translation files
Scanning directory './src'... Scanning directory './src/mumble'... Updating 'src/mumble/mumble_en.ts'... Found 1929 source text(s) (3 new and 1926 already existing) -
Merge pull request #4736: Backport "Use qInfo instead of qFatal for n…
…ormal logging" For some reason qFatal has been used to log information such as the version requested by the --version argument. abdb500 made qFatal exit with an exit status of one leading to successful operations that happened to contain some print-out to leave an exit status of 1 (#3911). Note: This is a backport of #3998
-
FIX(ocb2): Work around packet loss due to OCB2 XEX* mitigation
The mitigation for vulnerabilities discovered in OCB2 (https://eprint.iacr.org/2019/311, called XEX* attack, or XEXStarAttack, in code) introduced in be97594 (#4227) willingly allowed for some packets with specific characteristics to be dropped during encryption to prevent the vulnerability from being exploited. It was assumed that the chance of such packets was sufficiently small (given we are dealing with compressed audio) that such loss was acceptable. It was however discovered that digital silence (as produced by e.g. a noise gate) will cause Opus to emit almost exclusively such packets, leading to strong artifacts on the receiving end. See #4385. This commit tries to work around the issue by modifying such packets in a way which will no longer require them to be dropped, and yet produce the expected output on the receiver side. As far as I understand [Opus] (specifically section 4.1, 4.3.0 and 4.3.3), the 0s are simply unused bits and are only there because we running Opus in constant bitrate mode. So, flipping one of them should have no effect on the resulting audio. [Opus]: https://tools.ietf.org/html/rfc6716 Fixes #4719
-
Merge pull request #4739: Backport "FIX(client): Only allow "http"/"h…
…ttps" for URLs in ConnectDialog" Our public server list registration script doesn't have an URL scheme whitelist for the website field. Turns out a malicious server can register itself with a dangerous URL in an attempt to attack a user's machine. User interaction is required, as the URL has to be opened by right-clicking on the server entry and clicking on "Open Webpage". This commit introduces a client-side whitelist, which only allows "http" and "https" schemes. We will also implement it in our public list. In future we should probably add a warning QMessageBox informing the user that there's no guarantee the URL is safe (regardless of the scheme). Thanks a lot to https://positive.security for reporting the RCE vulnerability to us privately. This is a backport of #4733
-
Merge pull request #4738: Backport "FIX(ocb2): Work around packet los…
…s due to OCB2 XEX* mitigation" The mitigation for vulnerabilities discovered in OCB2 (https://eprint.iacr.org/2019/311, called XEX* attack, or XEXStarAttack, in code) introduced in be97594 (#4227) willingly allowed for some packets with specific characteristics to be dropped during encryption to prevent the vulnerability from being exploited. It was assumed that the chance of such packets was sufficiently small (given we are dealing with compressed audio) that such loss was acceptable. It was however discovered that digital silence (as produced by e.g. a noise gate) will cause Opus to emit almost exclusively such packets, leading to strong artifacts on the receiving end. See #4385. This commit tries to work around the issue by modifying such packets in a way which will no longer require them to be dropped, and yet produce the expected output on the receiver side. As far as I understand Opus (specifically section 4.1, 4.3.0 and 4.3.3), the 0s are simply unused bits and are only there because we running Opus in constant bitrate mode. So, flipping one of them should have no effect on the resulting audio. This is a backport of #4720
Commits on Feb 10, 2021
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 1.3.3...1.3.4