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.
CELT 0.11.0 provides better quality in comparison to CELT 0.7.0, but the two versions of the codecs are not compatible, which is why we provided both of them.
Opus was introduced in Mumble 1.2.4 (7586a61226), thus we expect that most (if not all) users are using it.
By removing CELT 0.11.0 we don't break backwards compatibility, because it's provided by CELT 0.7.0.
The main reason for removing the codec is the fact that its discontinued (in favor of Opus).
Also, CELT 0.11.0 was removed from the Debian package back in 2012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010
Unfortunately "sonar-scanner" fails with the following error:
ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:
* you are using the latest version of the build-wrapper and the SonarCFamily analyzer
* your compiler is supported
* you are wrapping your build correctly
* you are wrapping a full/clean build
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:239)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:82)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:403)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:399)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:362)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:98)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at com.sun.proxy.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:233)
at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123)
at org.sonarsource.scanner.cli.Main.execute(Main.java:77)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
The file is not generated because the C/C++ plugin library fails to load:
ERROR: ld.so: object '/home/travis/.sonar/cache/87f7532f0609a32b83c77be7ae487f14/build-wrapper-linux-x86/libinterceptor-${PLATFORM}.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Travis CI announced support for ARM64 builds a few days ago: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
We already have a Linux x86_64 build on Azure Pipelines, which also generates an AppImage.
This commit changes the architecture for the build we have on Travis CI, so that it's not redundant anymore (and becomes useful).
The "no-pch" build is not changed because the only differences consist in the PCH header not being used and the SonarQube Scanner being executed.
Also, we don't want to use an ARM64 builder unnecessarily.
This commit changes the Linux build script so that it retrieves the full Mumble version using mumble-version.py.
Previously we were using the first 7 characters of the commit hash as version, which is not very descriptive.
Copied from our current build environment, the header has been changed to match the one in the other scripts.
mumble-version.py determines the full Mumble version based on multiple variables, such as the current commit hash and the latest tag.
There's no reason to keep it in the build environment repository (mumble-releng), because it's supposed to be run inside the Mumble repository and doesn't depend on anything from the build environment.
Recent builds have failed because there is not enough space in `C:\` after installing the build environment, which we used to extract in `C:\MumbleBuild`.
This commit changes the PowerShell scripts so that our environment directory (e.g. `MumbleBuild`) is created in the proper directory (Agent.ToolsDirectory's value, e.g. `D:\a\_tool\`) instead of `C:\`.
`C:\MumbleBuild` is still required because our build environment's qmake expects its configuration files to be there (hardcoded). The environment installation script creates a symbolic link to solve the problem.
This should lower the overall CI completion time, because the macOS build seems to always take a while to start on Travis CI.
The macOS build will be removed from Travis CI in a dedicated commit.
Azure Pipelines offers many advantages over AppVeyor, with the biggest one being a maximum of 10 parallel builds for open-source projects, drastically reducing the builds completion time.
A pipeline takes about the same time to build on the two CI infrastructures, however the caching feature is currently only available on AppVeyor, meaning that on Azure Pipelines the compressed environment is downloaded for each build consuming about 10 minutes.
This means that we'll save at least 10 minutes per pipeline compared to AppVeyor once the feature is added to Azure Pipelines: https://github.com/Microsoft/azure-pipelines-tasks/issues/9190
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.
We install the protobuf package via brew, which depends on "python@2".
The build image upgraded the installed "python", and now "python@2" conflicts with it when trying to create symlinks.
We don’t use the symlinked "python" installed by default in the image, so we unlink it to allow the "python@2" package to be installed without conflict.
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.
