This originally started as a Linux-only improvement (support for "/etc/os-release"), but it became pretty clear that OSInfo was not in a pretty state.
Please note that the auto-update system is not affected, because it doesn't rely on OSInfo.
The most important change involves the OS name.
Before this commit we had "Win32", "WinX64", "OSX" and "X11". The latter was particularly misleading now that Wayland is a thing.
We now have "Windows", "Linux", "macOS", "FreeBSD", "NetBSD", "OpenBSD", "BSD", "UNIX" and "Unknown".
The second most important change is the way we retrieve the version on OSes other than Windows and macOS.
OSInfo had several methods, but none was aware of "/etc/os-release". We initially wanted to implement a new method, to be used as primary, that gathers info from that file.
However, we later realized we can just use QSysInfo because it does exactly what we planned to do on our own.
The reason why we're retaining our own methods for Windows and macOS is because they're MUCH more descriptive. For example, the build number is not in the strings returned by QSysInfo.
In order to make the code easier to read, the parts that handled versions of Windows we no longer support is removed.
The final change is about the info that is sent to our server.
"is64bit" was set to the correct value on all platforms except for Windows, because IsWow64Process() returns true only when the process is 32 bit and running on a 64 bit OS.
"arch" and "osarch" are introduced and represent the architecture of the program and the OS, respectively. "is64bit" is removed as it's now redundant.
"osverbose" is also introduced and represents the full operating system version.
According to https://www.freebsd.org/releases/ 12.1 is no longer
supported.
This also seemed to cause some problems in the most recent runs of the
Cirrus CI tasks.
Thus this commit updates the used version to 12.2
Now that we reached build number 10 the current expression is not valid anymore.
As a result, the version is not set and the build fails.
This commit rewrites the regex so that it accepts multiple digits and is also shorter.
Co-Authored-By: Jan Klass <kissaki@posteo.de>
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 PR 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 us the RCE vulnerability privately.
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.
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.
Fixes#4719
GlobalShortcut::buttonName() and GlobalShortcut::buttonText() are removed in favor of GlobalShortcut::buttonInfo().
The new function returns a ButtonInfo structure, which contains two strings: one identifies the device, the other one the button.
ShortcutKeyWidget is removed, as replaced by GlobalShortcutButtons.
This is a dialog that allows to efficiently view/add/remove buttons for a specific shortcut.
The tree design allows to easily identify the buttons and the device they're attached to.
The capture process can be started by pressing on "Add".
Once all buttons are released the process stops automatically.
There's only a cosmetic issue, that should be fixed in our theme: no distinction between active and focused QPushButton.
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/rfc6716Fixes#4719
This language no longer exists on Transifex. (Removed empty duplicate to more generic language without locale.)
The file seems to not contain any translations.
There is the more general nl translation file.
Previously, duplicate translation files were removed in three commits:
b208fe0 ca_ES
70091f8 el_GR
c043423 nb_NO
These files were not removed from the CMakeLists.txt and translations.pri.
Previously, duplicate translation files were removed in three commits:
b208fe09d1 ca_ES
70091f8fea el_GR
c0434236f1 nb_NO
These files were not removed from the CMakeLists.txt and translations.pri.
These were requested and approved at some point in Transifex.
However, no work was ever done on translating to them.
With the imminent move to another translation platform,
we take this opportunity to prune empty translations from it.
These translations can be added upon request again, just like any other.
But they served no value as empty, dead translation files with no progress.
These were requested and approved at some point in Transifex.
However, no work was ever done on translating to them.
With the imminent move to another translation platform,
we take this opportunity to prune empty translations from it.
These translations can be added upon request again, just like any other.
But they served no value as empty, dead translation files with no progress.
I have no idea why but these changes make this work on my Windows 10 VM.
If this really solves the issue then this is a perfect illustration for
why batch is weird.
I have no idea why but these changes make this work on my Windows 10 VM.
If this really solves the issue then this is a perfect illustration for
why batch is weird.
The class was defined in AudioWizard.cpp/.h, however AudioWizard is not the only user.
In fact, Cert.ui had to include AudioWizard.h in order to make use of CompletablePage.
This commit moves the class into a dedicated file set and changes the include header in AudioWizard.ui and Cert.ui.
This fixes the last build failure, which was due to the job's display name containing spaces.
"x86_64" is changed to "x64" as the latter appears to be the most common identifier for the architecture, at least for Windows.
Turns out environment variables cannot be exported globally:
"/.ci/azure-pipelines/main.yml (Line: 7, Col: 1): Unexpected value 'env'"
It has to be done for each step that makes use of the variable.
Furthermore if a variable is not defined on Azure, the expansion
$(MY_VARIABLE) does not resolve to an empty String (as is the case e.g.
in Bash) but this expression is then taken literally without any
expansion at all. Therefore we have to make sure that the
BUILD_NUMBER_TOKEN variable is always defined. Thus we define it in
main-pr.yml as for PRs we don't define it on Azure.
In order for these variables to not interfere with each other, the
variable name inside the scripts was prefixed with MUMBLE_
Turns out environment variables cannot be exported globally:
"/.ci/azure-pipelines/main.yml (Line: 7, Col: 1): Unexpected value 'env'"
It has to be done for each step that makes use of the variable.
Furthermore if a variable is not defined on Azure, the expansion
$(MY_VARIABLE) does not resolve to an empty String (as is the case e.g.
in Bash) but this expression is then taken literally without any
expansion at all. Therefore we have to make sure that the
BUILD_NUMBER_TOKEN variable is always defined. Thus we define it in
main-pr.yml as for PRs we don't define it on Azure.
In order for these variables to not interfere with each other, the
variable name inside the scripts was prefixed with MUMBLE_
The following icons were added (with a description) to Qt's "What's
this?" help system:
- padlocks (#3929)
- talking state for locally muted users (#4322)
- listener symbol (#4011)
Fixes#4686
We used mumble-vcpkg while the get script was still being implemented in a separate repository.
When we integrated it in this repository in 2f45772 it was already, and still is, using vcpkg.
We used mumble-vcpkg while the get script was still being implemented in a separate repository.
When we integrated it in this repository in 2f45772c9c it was already, and still is, using `vcpkg`.
Clients < 1.4.0 don't know about the new ChannelListener feature and
thus there is no indication in the UI for them. In order to make sure
that users know that they could potentially be listened to without
seeing anything in the UI, a warning message was introduced in #4097.
There was an error in the implementation however causing this warning to
not be sent by the server if there are no explicit limits on the amount
of channel listeners via the server configuration.
The bug was that "no limit" was expressed as -1 but the check for
whether these features are enabled checked for > 0. The fix is simply to
check for != 0 instead.
Fixes#4687
