Hi Chris,
Am 24.06.2012 21:51, schrieb Chris Knadle:
I'm a bit dissappointed by the reply you got back to this suggestion, so I'm
adding some thoughts concerning your idea.
*Many* thanks for taking my mail seriously, which the maintainer
obviously did not. And yes, I am also rather disappointed about Rons
reaction.
On Saturday, June 23, 2012 15:54:07, Michael Schmitt wrote:
Hi folks,
I guess shipping both versions with wheezy is not a viable option? At
least I think that it would make sense. Disclaimer in the readme,
explanation of the situation, if a major security exploit does surface
(a mumble-client-crash is not a major security risk imho), remove that
second version (if there is no somewhat easy fix at that time). Call the
package mumble-client-buggy that conflicts with the "normal" client and
I guess all users can decide on their own if they want to be safe or
actually talk to other people.
What you're proposing concerning adding a 'mumble-client-buggy' could
technically be done /in theory/ and even occasionally has been in other
packages; the packages 'gobby' and 'gobby-0.5' are an example. If you look
these binary packages up, you'll see they have two different source packages
too -- 'gobby' and 'gobby-infinote'. The reason these exist is that the two
versions of the software are incompatable by design, and 'upstream' still
offers both versions.
The situation in with mumble differs slightly there... but more about
that later.
Debian Wheezy is extremely close to being frozen in preparation for releasing
the next version of Debian Stable -- a "buggy" package destined for the
"stable" release would have to be justfied and would likely be rejected by the
ftpmasters after upload if it couldn't be. Plus it sounds like there are
several other issues to handle.
Substitute "buggy" with "unsupported" or anything else that might sound
sane. And the situation is quite clear and I do understand there are
several valid point of views. Even if Ron lacks some... ehm... whatever,
technically I do understand his point. But what other issues are there,
apart from *possible* security exploits?
These types of decisions are generally up to the maintainer of the package as
to how to proceed. It's clear the maintainer for mumble is frustrated right
now,
Frustration... I see, that's how they call it. ;)
because (IMHO) there isn't a clear path as to how to proceed here.
That just depends on the various POVs, and every POV has a straight
path... imho. If you just don't have a somewhat solid POV yet, different
story for sure. ;)
Several options are possible, but nothing seems to exactly fit -- removing the
CELT codec breaks communication with popular older mumble/murmur servers,
leaving the codec in has security and support implications,
That depends how one "reads" upstreams statement about that issue, which
is (iirc) "we don't drop celt in mumble, if a problem with celt faces,
we will react / try to fix it". So imho, no real security issues. But
yes, one may say there needs to be done a complete celt code-review so
that assurance from upstream... one valid POV there could be "not
enough, celt must be dropped".
My point there is: No real exploits known yet, leave celt 0.7 and 0.11.1
in mumble (as upstream does), if real security exploits rise ->
communicate with upstream and take it from there.
making both
packages available would require going through the NEW queue at the last
minute and would additionally risk being rejected.
Sure, a not-so-good alternative, but a valid option nevertheless.
Because of all these sticky problems, without a clear path to proceed if I
were personally in the maintainer's shoes I'd probably take the "do nothing"
option and release the current "348" version that has the libcelt0-0 codec
that has issues but retains compatability with older popular mumble servers.
I wouldn't /like/ this option though, because I'd have to support it for two
years, and upstream isn't supporting the buggy CELT 0.7.1 codec at all.
Afaik, wrong. Upstream does support (as described above) both celt
incarnations (built-in). And only the current debian package does not
include celt (and the external lib was removed). I wonder how other
distros will handle this...
In general, I had a few words with some mumble devs on IRC a few days
back. Common thinking there was, removing celt is not a wise option, no
real security exploits known yet, mumble will support celt for the
foreseeable future (1 - 2 years).
And as we have security.debian.org, IF a problem faces next year, valid
option there is to remove celt from the mumble package again and we had
many months for the rest of the mumble world to upgrade to a newer /
compatible version. A sidenote there: Opus is still just a draft! So
removing celt now with the explanation "Opus is there, no need for celt
anymore" is at least not completely valid.
The question is just, where does one stand. And, can we convince the
maintainer to change his POV (which I somehow doubt...).
regards
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
