[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#682010: marked as done ([mumble] Communication failures due to CELT codec library removal)

Your message dated Thu, 30 Aug 2012 11:12:24 -0700
with message-id <20120830181224.GG6394@rzlab.ucr.edu>
and subject line Re: Bug#682010: Call for votes on CELT in Mumble
has caused the Debian Bug report #682010,
regarding [mumble] Communication failures due to CELT codec library removal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
682010: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682010
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
Severity: normal


Greetings to the technical committee.

This refers to Bug #675971 (which is severity grave, and currently closed)
against the Mumble VoIP package, which is also affected by Bug #674650
concerning the removal of the CELT library.  This evening we also just
discovered the existence of Bug #674634 which concerns the CELT library
removal as well, and which may have more of the technical story.


Summary of the technical dispute
================================

Point of view of bug reporters (text via collaboration of two reporters):

  Background:
  ----------

- Mumble upstream uses and requires a particular baseline audio codec
  (CELT 0.7.1, a fairly old version), the availability of which is a
  base assumption used by most Mumble servers.

- CELT's upstream has a planned transition to the standardized Opus
  codec, and Mumble plans to follow suit, but that transition won't
  complete until all clients and servers support Opus, and that will take
  a while.  (Also, current upstream support for Opus remains a work in
  progress, and they don't have a released version with non-buggy
  support for Opus yet; the current version in Debian has some
  cherry-picked patches from upstream's VCS, but that doesn't help
  non-Debian users.)

- CELT audio Codec library has been removed from Debian by the maintainer,
  which with Mumble today is causing audio to fail outright for many public
  servers as well as several prior versions of mumble-server from Debian.
  [This has also been a problem for several other audio packages and
   maintainers.]

- On newer Mumble server versions, the audio connection fails if another
  client connects that requires using CELT, because all connected clients
  require using a common Codec.

- The newest -2 upload contains this issue.  [Mentioned because the
  maintainer reported that the -2 upload fixes the bug.]

- There is no warning in the NEWS.Debian file to warn users of the
  package that only the Opus Codec is usable and how that impacts the
  usability of the package

- The bug is repeatedly being closed by the maintainer if it was fixed,
  without discussion.  [Josh Triplett has since tagged the bug "wontfix",
  which is at least an improvement, but this RC-level bug remains closed
  as is being forced by the maintainer, which will presumably allow the -2
  package with this issue to migrate to Wheezy and release with Stable.]

  Desired:
  -------

- From the point of view of the bug reporters, what we want is a
  package that inter-operates with other Mumble clients and servers,
  if possible.  To do this today would require reintroducing the celt
  source package again, which is rumored to have potential security issues.
  [We have not seen any details on this yet.]

  Note: this evening we think we have found a security expert who is
  willing to audit the CELT 0.7.1 codec for issues and possibly provide
  patches, assuming this is reasonably feasible.

- Assuming an inter-operable package is not possible, as a backup what
  we want is for the bug to be handled correctly in some way, and that
  users of the package have an opportunity to be notified of what
  limitations the package has.

  Possible options:
  ----------------

- Leave mumble out of testing and wheezy, keep it in either unstable
  or experimental (as we would for any client-server software with an
  unstable protocol that we can't support for the lifetime of a stable
  release), reintroduce CELT library for use with Mumble with security
  warnings in the description and NEWS.Debian concerning potential issues.

- Let mumble 1.2.3-349-g315b5f5-2 migrate to testing and release with
  wheezy without the CELT library, with compatibility warnings in
  NEWS.Debian. Possibly reintroduce (or at least allow the use of) a CELT
  codec library for Mumble in Unstable or Experimental which could allow
  users to use the CELT codec library with Mumble, with a warning in
  NEWS.Debian for the celt package to warn of potential issues.

- Similar to the item above, but with the CELT library in an external
  repository.

- Some other alternative we haven't thought of.



Point of view of the maintainer (as understood by reporters thus far, as
  no reply was given in several days in query for this summary):

- Someone the maintainer trusts said the CELT library contains code that
  could potentially be a crash vulnerability, among other unfixed issues

- Nobody is committing to maintaining and taking responsibility for celt
  0.7.1, or has sufficient spare time and/or the requisite knowledge to
  fully investigate this further.

- It was decided to remove the CELT library as to not burden the security
  team, and it has been an effort to get the library removed

- The mumble client that we currently have will only inter-operate with
  clients that have Opus support

- Upstream is eventually planning on dropping CELT anyway

- This isn't a bug, so it should be closed, and there is no need to warn
  users of the package

================================



I've subscribed to the tech-ctte mailing list, so I don't need to be CCed.
We're prepared to accept any possible outcome the TC deems appropriate.

Thanks.

  -- Chris

--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
--- Begin Message --- 
With the vote of Andreas, the outcome is no longer in doubt.
Therefore, the Technical Committee resolves:


  Context:

  1. The questions surrounding the codecs in mumble, especially celt,
     have been referred to the Technical Committee.

  2. The mumble maintainers have stated their willingness to follow
     our advice (Constitution 6.1(5)).  This may or may not amount to
     a delegation to us of the decision (6.1(3)) but in any case we
     merely need to state our reasoning and conclusions and are not
     being asked to overrule the maintainer.

  Release Critical status of celt 0.7.1 in mumble:

  3. mumble is a useful and fairly widely-used voice chat program.

  4. Distributions of mumble (from other distros and upstream)
     currently implement the celt 0.7.1 codec as a baseline.  It does
     not appear to the TC that (in wheezy) the provision of any other
     codec obviates the need for mumble to support celt 0.7.1.
     mumble with celt 0.7.1 has been tested and found to interoperate
     properly with nearly all other mumble versions.

  5. Consequently, we consider the lack of celt 0.7.1 support in
     mumble a release-critical bug.

  Security risks from celt 0.7.1:

  6. While the upstream security support situation for celt 0.7.1 is
     not ideal, the TC does not consider that the security risks
     associated with celt 0.7.1 in mumble are intolerable.

  7. The Debian Security Team have stated that they have no objection
     to including celt 0.7.1 in mumble in wheezy.

  8. Consequently, mumble should remain in wheezy with celt 0.7.1
     (the alternative being to remove mumble as unfit for release).

  Packaging approach:

  9. There are no other packages intended for wheezy which ought to
     want this codec.

  10. Providing separate celt library in wheezy is undesirable because
     it might promote the use of a codec which we are planning to
     retire in the medium to long term.

  11. While embedded code copies are in general to be avoided because
     lead to proliferation of multiple versions, that therefore does
     not apply in this case.

  12. The upstream mumble source already contemplates building with
     various embedded versions of celt.

  13. There is no reason to support any other version of celt in
     mumble.

  14. Consequently, the mumble source package should be configured to
     use an embedded copy of celt 0.7.1.  (If necessary the embedded
     copy of celt in the source package should be updated to the
     actual 0.7.1.)

  We therefore recommend that:

  15. The mumble maintainers, with appropriate help from other
     interested parties, should prepare an upload of mumble for wheezy
     with
       - embedded celt 0.7.1 enabled
       - no other version of celt enabled
       - whatever other release-critical bugfixes they consider
          relevant (subject to any appropriate discussion with the
          release team as necessary)
       - closing #675971.

  16. #675971 should remain at an RC severity, be untagged wontfix,
     and maintained open until it is closed as discussed above.

  17. If the release team are content with the other changes
     in the new mumble package, the new version should be unblocked
     to propagate into wheezy.

  18. After that propagation, the separate celt packages should be
     removed from wheezy.  This should be requested by the celt
     maintainer filing a removal bug in the normal way, after mumble
     with embedded celt 0.7.1 has propagated to wheezy.


Don Armstrong

-- 
I learned really early the difference between knowing the name of
something and knowing something
 -- Richard Feynman "What is Science" Phys. Teach. 7(6) 1969

http://www.donarmstrong.com              http://rzlab.ucr.edu

--- End Message ---
Reply to: