Commits on Aug 8, 2014
  1. Update changelog

    mkrautz committed Aug 8, 2014
  2. scripts: modify to work on the currently checked-out branch…

    mkrautz committed Aug 8, 2014
    … rather than origin/master.
Commits on Jul 23, 2014
  1. PulseAudio: don't call pa_stream_drop() for empty pa_stream_peek().

    mkrautz committed Jul 23, 2014
    It is now explicitly spelled out in the PulseAudio docs that one
    must not call pa_stream_drop() when the buffer peeked via
    pa_stream_peek() is empty.
    This change fixes our calls to pa_stream_drop() to comply with the
    new wording.
    Fixes #1317
    (cherry picked from commit 63f35d6)
  2. PulseAudio: stricter pa_stream_peek() validation.

    mkrautz committed Jul 20, 2014
    An uncommon condition in the pa_stream_peek function
    ('no data at current read index') wasn't handled properly
    and could lead to a segfault.
    The commit also adds checks for other pa_stream_peek
    error scenarios.
    Fixes #1316
    (cherry picked from commit e740ea5)
Commits on Jul 4, 2014
  1. PulseAudio: fix access to protected enums in AudioInput and AudioOutput.

    mkrautz committed Jul 2, 2014
    The SampleFormat enums in AudioOutput and AudioInput are meant to be
    used in subclasses of AudioOuptut and AudioInput, and because of that,
    they're marked protected.
    PulseAudioSystem has used these protected enums for some time, without
    triggering any warnings. However, recent versions of Clang error out
    on this behavior (and rightly so).
    To fix this issue, this change modifies PulseAudioSystem to access the
    SampleFormat enums via PulseAudioOutput and PulseAudioInput, instead
    of going through AudioOutput and AudioInput directly. PulseAudioSystem
    is already a friend class of PulseAudioOutput and PulseAudioInput, so
    it can access the protected members of AudioOutput of AudioInput just
    fine, as long as it happens via PulseAudioOutput and PulseAudioInput.
    Originally reported on the Debian BTS (as #753273) by
    Alexander <>
    Reported on the Mumble issue tracker (as #1302) by
    Chris Knadle <>
    (cherry picked from commit 01a5e83)
Commits on Jul 2, 2014
  1. mumble: fix VoiceRecorderDialog build on Apple clang-500.1.70.

    mkrautz committed Aug 2, 2013
    (cherry picked from commit 4c48f72)
  2. installer: add the ability to use a custom bzip2 directory in the Win…

    mkrautz committed Jul 2, 2014
    …32 installer.
    Previously, the bzip2.dll was always taken from the Ice directory.
    This is because we previously used ZeroC's binary Ice releases, which
    included a bzip2.dll that we could use.
  3. installer: fix ability to use a custom OpenSslDir when building the W…

    mkrautz committed Jul 2, 2014
    …in32 installer.
    The actual assignment was missing an "env." prefix.
Commits on Jun 30, 2014
  1. bonjour: use Qt::AutoConnection for BonjourServiceResolver's QSocketN…

    mkrautz committed Jun 8, 2013
    …otifier slot.
    Using a QueuedConnection for the slot had the unpleasant
    side effect that the QSocketNotifier could have its activated()
    slot invoked even though no data was waiting to be read.
    In our case, this could cause a deadlock inside Avahi's
    libdns_sd compatibility library.
    I've settled on using Qt::AutoConnection to be consitent
    with the rest of the code base. The Bonjour code should
    always be invoked from the main thread, so in this case
    Qt::AutoConnection will always mean Qt::DirectConnection.
    Why does this happen?  Qt seems to process events before
    invoking queued slot invocations.  If the Qt event loop
    finds that the file descriptor that our QSocketNotifier
    is providing notification for is ready for reading, it
    queues up an invocation of the activated() slot for the
    next event loop iteration (because we use a QueuedConnection).
    As mentioned above, because Qt seems to poll() FDs before
    invoking queued-up slots, the end result is that an
    invocation of the activated() slot for a given
    QSocketNotifier's file descriptor can be queued up in
    the very same event loop iteration that a read() is
    performed for the exact same file descriptor.
    After performing the read(), the queued-up activated()
    slot invocation is no longer valid, and can wreak havoc,
    which in our case causes a deadlock in the Avahi libdns_sd
    The flow below describes the event loop iterations
    in more detail:
    1st event loop iteration
    * poll() is invoked; the QSocketNotifier's FD is
      ready for reading.
    * An invocation of the activated() slot is queued
      up, to be executed next time we enter the event
      loop (due to Qt::QueuedConnection).
    2nd event loop iteration
    * poll() is invoked; the QSocketNotifier's FD is
      _still_ ready for reading.
    * An invocation of the activated() slot is again
      queued up, to be executed in the 3rd iteration.
    * The queued-up slot invocation from the 1st iteration
      is invoked. (read() is called.)
    3rd event loop iteration
    * poll is invoked(); the QSocketNotifier's FD has
      nothing to read anymore. Everything was read in
      the activated() slot that was invoked in the
      2nd iteration.
    * The queued-up slot invocation from the 2nd iteration
      is invoked. This time, the read() syscall will block,
      because there is nothing to read.
Commits on Jun 29, 2014
Commits on Jun 14, 2014
  1. Bump version to 1.2.8

    mkrautz committed Jun 14, 2014
  2. Update changelog

    mkrautz committed Jun 14, 2014
Commits on Jun 12, 2014
Commits on Jun 11, 2014
Commits on Jun 10, 2014
Commits on Jun 5, 2014
  1. Bump version to 1.2.7

    mkrautz committed Jun 5, 2014
Commits on May 13, 2014
  1. Update changelog

    mkrautz committed May 13, 2014
  2. Bump version to 1.2.6

    mkrautz committed May 13, 2014
  3. mumble: fix Mumble-SA-2014-006.

    mkrautz committed May 13, 2014
    Usernames and channel names were not properly HTML-escaped
    when used in Qt widgets that are rich-text enabled.
    This commit fixes that, but also touches various other
    similar cases where an escaped version is appropriate.
    This commit is based on the following commits from the
    master branch (Mumble 1.3.0):
    Special thanks to Tim Cooper for various of the above
  4. mumble: fix Mumble-SA-2014-005.

    mkrautz committed May 13, 2014
    Qt's SVG image plugin is not safe to use with potentially
    unsafe SVGs, such as those downloaded over the network.
    More specifically, it is possible to trigger local file
    access via Qt's SVG renderer using SVG features such as XML
    stylesheets (XSL) and SVG image tags, and potentially other
    features. This allows an attacker to have Qt read arbitrary
    files into the memory space of the Mumble process.
    This makes it easy to perform a Denial of Service attack
    against a Mumble client. A client DoS can be accomplished
    by serving it an SVG file that refers to a filesystem path
    that is un-ending or is known to block under certain
    Having arbitrary files read into the Mumble process could
    potentially also be abused by an attacker to gain access
    to the content of the files, if combined with an (as of
    yet unknown) vulnerability that allows the attacker to
    read Mumble's memory.
    To fix the issue, this change removes SVG as a supported
    image format for all externally received images. This
    includes things such as text messages, user comments,
    channel comments and user textures/avatars. It also removes
    the ability to transmit SVGs using any of the aforementioned
    This is accomplished by introducing a new class called
    RichTextImage. The RichTextImage class is used, via its
    isValidImage() method, to validate images before they are used
    in a rich text context in Mumble. In its current form, the
    isValidImage() method simply checks whether the image's format
    is part of the set of image formats that are deemed safe
    (PNG, JPG, GIF).
    The LogDocument class, which is the QTextDocument that backs
    the Mumble log view, undergoes the following changes:
     - LogDocument now restricts images loaded via QNetworkRequest
       and QNetworkReply to those that pass the
       RichTextImage::isValidImage() check.
     - Resources that use the data:// scheme are now loaded via
       QNetworkRequest and QNetworkReply, just like http:// and
       https:// URLs. This allows all resources to make use of
       LogDocument's new image format restrictions.
     - The functionality of the ValidDocument class, a subclass
       of LogDocument that was used to validate HTML snippets,
       is now part of LogDocument itself. The original
       ValidDocument class has been removed.
    The RichTextEditor class is used to author text messages
    and user comments. The RichTextEditor is changed to use
    a LogDocument instead of a regular QTextDocument as its
    backing document. This allows the RichTextEditor to benefit
    from LogDocument's new image filtering functionality.
    The static method Log::validHtml is used to validate
    HTML before using it in various contexts such as the Mumble
    log view and tooltips. This method is modified to use the
    LogDocument class instead of the ValidDocument class.
    A call to documentLayout() on the LogDocument is also
    added to the method. This ensures that image loading
    (and thus validation) is performed.
    The MainWindow::openImageFile() method is re-worked to
    sniff and validate a selected image using
    RichTextImage::isValidImage to ensure that only valid
    rich text images can be selected, regardless of file
    The Overlay::verifyTexture() method is used to verify and
    set a ClientUser's texture and texture format, either by
    reading it from the local cache, or by reqesting a new
    texture from the server. This method is changed to only
    verify and set textures that pass the
    RichTextImage::isValidImage() check.
    The ServerHandler::setUserTexture() method (also known as
    ServerHandler::setTexture() in some 1.2.x versions of Mumble)
    is changed to only allow settings textures that pass the
    RichTextImage::isValidImage() check.
    Thanks to Tim Cooper for reporting this issue, proposing an
    initial patch and reviewing the final patch. This commit has
    also been reviewed and iterated upon by Stefan Hacker.
Commits on Jan 31, 2014
  1. Update changelog

    mkrautz committed Jan 31, 2014
  2. Bump version to 1.2.5

    mkrautz committed Jan 31, 2014
Commits on Jun 1, 2013
  1. Update changelog

    hacst committed Jun 1, 2013
  2. Server::sendMessage: encode the source IP of outgoing UDP packets to …

    mkrautz committed May 31, 2013
    …match the UDP socket's address family.
    Murmur uses the saiTcpLocalAddress field of ServerUser to determine
    the correct source address of outgoing UDP packets. On some systems,
    such as multi-homed setups, this is important for correct datagram
    The saiTcpLocalAddress field is initialized when the client first
    connects. Its value is extracted from QHostAddress, and then
    converted to a sockaddr struct via our own HostAddress class's
    toSockAddr method.
    HostAddress::toSockAddr is implemented such that any IPv4 address
    (including IPv4-mapped IPv6 addresses) will always cause a sockaddr
    struct belonging to the AF_INET (IPv4) family to be output. Pure IPv6
    addresses will be output as an AF_INET6 sockaddr.
    The code that this change touches assumed that it could use the
    value of saiTcpLocalAddress directly as the source address in UDP
    This is not always the case. On most systems, Murmur will listen on
    [::]:64738 by default, and as such, the address of the server's UDP
    socket will be in the AF_INET6 family. Attempting to send packets
    with a source address in the AF_INET family using that socket will
    cause sendmsg() to return EINVAL on some systems, if not all.
    The new code for the sendmsg() code path converts the ServerUser's
    saiTcpLocalAddress back into a HostAddress, which, internally, is
    fully IPv6. If the input address is IPv4, HostAddress will convert
    it to an IPv4-mapped IPv6 address.
    When the client's UDP socket is of the AF_INET6 family, we can now
    trust that the HostAddress, 'tcpha', is either a real IPv6 address,
    or an IPv4-mapped IPv6 address. This allows us to use the 'tcpha'
    address regardless of the address family of the saiTcpLocalAddress.
    We can simply memcpy it in place.
    When the UDP socket is of the AF_INET family, we can only set the
    source address if the saiTcpLocalAddress is also AF_INET, or if
    it is of the AF_INET6 family and its address is an IPv4-mapped IPv6
    address. When a pure IPv6 address is encountered in that path, it is
    simply dropped.
Commits on May 11, 2013
  1. Minor fix in pl translation

    Zuko authored and hacst committed Feb 20, 2013
Commits on Mar 28, 2013
Commits on Mar 27, 2013
  1. Ensure that the MAX macro is always defined.

    gagern authored and mkrautz committed Mar 18, 2013
    On some systems, none of the (directly or indirectly) included headers does
    provide that macro. First reported in
Commits on Mar 19, 2013
Commits on Feb 2, 2013
Commits on Jan 27, 2013
  1. ConfigDialogDelegate: return fully standalone NSImage in QIcon_to_Aut…

    mkrautz committed Jan 27, 2013
    QPixmap::toMacCGImageRef seemingly returns an NSImage that is still backed
    by the QPixmap. With semantics like that, our usage doesn't make much sense.
    For now, use the private QtGui symbol qt_mac_create_nsimage() to create
    a fully standalone NSImage.
Commits on Jan 20, 2013
  1. BF3 PA plugin update: fixed one value

    bogie authored and hacst committed Jan 19, 2013