When building on a Mac -Doverlay=OFF, the compiler would produce a
warning about an unused variable in the macOS shortcut implementation.
This commit silences the warning, by explicitly marking the variable in
question as unused.
Fixes#5636
When building on a Mac -Doverlay=OFF, the compiler would produce a
warning about an unused variable in the macOS shortcut implementation.
This commit silences the warning, by explicitly marking the variable in
question as unused.
Fixes#5636
the the docker image that is built by default uses murmur user to run
the server. When users use bind mount volumes, the host system is
expected to match the permissions (UID/GID) of the created murmur user
or else they will get permission errors
this change allows users who build the docker image to specify which
user id and group id to be used in the docker image
Closes#5634
1d45d99 refactored the audio processing
on the server and introduced the new AudioReceiverBuffer class. In the
function that is responsible for obtaining the current range of
receivers that shall obtain the identical audio packet, the passed begin
iterator was always dereferenced. However, in the case in which the
receiver list is actually empty begin == end and therefore dereferencing
the begin iterator is undefined behavior.
This could lead to the entire server crashing (or could work just fine -
UB is great at this) but in any case, this is a severe problem.
The fix consists of a simple check for this specific situation and an
early return in that case.
1d45d991aa refactored the audio processing
on the server and introduced the new AudioReceiverBuffer class. In the
function that is responsible for obtaining the current range of
receivers that shall obtain the identical audio packet, the passed begin
iterator was always dereferenced. However, in the case in which the
receiver list is actually empty begin == end and therefore dereferencing
the begin iterator is undefined behavior.
This could lead to the entire server crashing (or could work just fine -
UB is great at this) but in any case, this is a severe problem.
The fix consists of a simple check for this specific situation and an
early return in that case.
Co-Authored-By: Irak Rigia <tarakrigia@gmail.com>
Received compiler warning of an assert that is always true.
The assert checked if variable is negative but it is an unsigned variable.
Just check if positive.
Having plain http as the default means that a site, even though able to support https, will be able to fall back to using the insecure and outdated protocol.
Furthermore, major browsers already support https by default, falling back to legacy http in the cases where a website does not support https connections, e.g. Chromium, Firefox.
Therefore, this commit makes it so that a link without a protocol specification will have https:// prefixed to be clickable instead of http://.
As reported in #4491, #4986 and #5430, since the changes to the chat in
the 1.4.x release, some tags would "pollute" the rest of the log, i.e.
cause future log entries to be contained within them.
The source of the issue seems to be that the insertBlock method of
QTextCursor appears to correspond to the <p> HTML tag. The <p> tag
may only contain inline elements, but QTextEdit will not fail outright
when inserting block-level elements and will instead attempt to correct
the invalid input which results in the behaviour reported in the above
issues (as far as I can tell).
The proposed solution is to use the insertFrame method for all
messages.
Fixes#4491
Having plain http as the default means that a site, even though able to support
https, will be able to fall back to using the insecure and outdated protocol.
Furthermore, major browsers already support https by default, falling back to
legacy http in the cases where a website does not support https connections,
e.g. [Chromium](https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html),
[Firefox](https://blog.mozilla.org/security/2021/08/10/firefox-91-introduces-https-by-default-in-private-browsing/).
Therefore, this commit makes it so that a link without a protocol specification
will have `https://` prefixed to be clickable instead of `http://`.
Signed-off-by: mataha <mataha@users.noreply.github.com>
As reported in #4491, #4986 and #5430, since the changes to the chat in
the 1.4.x release, some tags would "pollute" the rest of the log, i.e.
cause future log entries to be contained within them.
The source of the issue seems to be that the `insertBlock` method of
`QTextCursor` appears to correspond to the `<p>` HTML tag. The `<p>` tag
may only contain inline elements, but `QTextEdit` will not fail outright
when inserting block-level elements and will instead attempt to correct
the invalid input which results in the behaviour reported in the above
issues (as far as I can tell).
My proposed solution is to use the `insertFrame` method for all
messages.
Fixes#4491
Without this, building against the latest poco snapshot results in errors like:
/usr/bin/ld: /builddir/build/BUILD/mumble-1.4.230.src/src/mumble/PluginManifest.cpp:72: undefined reference to `typeinfo for Poco::XML::Element'
Without this, building against the latest poco snapshot results in
errors like:
/usr/bin/ld: /builddir/build/BUILD/mumble-1.4.230.src/src/mumble/PluginManifest.cpp:72: undefined reference to `typeinfo for Poco::XML::Element'
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
The automatic upgrade from VS2019 to VS2022 broke our build and in order
to prevent that in the future, we now pin the used VS version to 2022.
Later upgrades will have to be performed explicitly.
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
NOTE: When this gets merged, all clients and servers claiming to support the protocol version 1.5.0 that do not include these changes, will become incompatible with the ones that do integrate these changes. This is important for everyone closely following our upstream master branch. A simple update to the latest code changes (including the changes from this PR) should be enough to restore full compatibility.
All servers and clients of version < 1.5.0 will be not affected by this as this PR is completely backwards compatible with those clients.
The update includes the changes made to the upstream code since 2016
plus an additional fix for a memory leak encountered in Mumble's usecase
(in the new audio cache implementation introduced with switching Mumble
audio to the Protobuf format).
This message type is explicitly handled before calling into the
different msg* implementations. Therefore, msgUDPTunnel could never be
called in the current state of the code base.
However, we can't remove the implementation completely, because of the
macro voodoo that is used to declare and switch over the different
message types (we can't remove the entry from the macro, since in there
we still need it for defining the respective enum entry).
Previously the opusthreshold config option had a default value of 100
meaning that the first non-Opus client would cause everyone to fall back
to one of the legacy codecs.
Since Opus has been implemented for ages now and we eventually want to
get rid of the legacy codecs, this commit changes the default value of
this config option to be zero, meaning that the server will always
enforce the use of the Opus codec (regardless of what clients are
connected).
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
ght now we are using osxdist.py to generate a DMG package from scratch.
The script also takes care of signing the content.
However, our mumble-releng repository has had a dedicated script called sign-dmg.py since 2013.
In fact, that's what we have always been using to sign the app bundle.
As we're planning to eventually ditch osxdist.py in favor of CPack's generator, we decided to complete sign-dmg.py.
The script now:
Takes care of signing all binaries in the bundle in addition to it, effectively replacing osxdist.py.
Supports single binaries, replacing sign-mach-o.py (which only called codesign() from sign-dmg.py).
Supports PKG packages.
Provides a --config option to specify the path to the configuration file. Default: $HOME/.sign_macOS.cfg.
Provides a --entitlements option to specify the path to the plist file containing the requested capabilities.
This is mandatory for notarization to succeed. More specifically, the --options runtime codesign parameter is.
The parameter is not passed if this option is not used because it would cause Mumble to crash upon audio input use.
The name is changed to sign_macOS.py as the script does not only handle DMG packages anymore.
In the server browser, the tooltip for the different entries shows the
packet loss. It is displayed as a percentage and as a x/y stat. The
latter currently displays <received>/<sent> which is very confusing,
given that the title for that row is "Packet loss" implying x would
describe the lost packages instead of the received ones.
Thus this commit changes this to the expected behavior. Furthermore it
makes sure that <lost> is always <= <sent>.
Besides the typedef that is meant to be used in code, there is also one
that encodes a type of the exact size (32bit) a raw version is expected
to have.
The "Guidelines Support Library" (GSL) is a library that implements
functions and types suggested by the C++ Core Guidelines. This should
make it relatively straight forward to follow these guidelines and thus
to write better C++ code.
This explicitly adds the Microsoft GSL as that seems to be the most
popular (and complete) GSL implementation available.
