Bug#675971: what should we be doing?
On Wed, Jun 27, 2012 at 02:51:23PM -0400, Chris Knadle wrote: I've re-read what you had written to at least try to understand what options there there might be. If possible, I'd like some clarification on what the zero-ice snafu in the following statement means: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672066#54 Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#675971: what should we be doing?
Hi, On Tuesday 26 June 2012 23:33:39 Chris Knadle wrote: I'm assuming all of the above is true under normal circumstnaces when CELT 0.7.1 support is included. However with libcelt0-0 removed, mumble version 1.2.3-349-g315b5f5-1 is unable to communicate via server loopback to the majority of the public mumble servers (at least in the United States) all of which seem to have versions = 1.2.3. Protocol support for Opus was only enabled in fairly recent development versions, so server builds that are based on 1.2.3 and only include selected upstream patches will most likely not advertise it. Effectively, the standardisation process and related resolution of licensing issues for the new codec are one of the things holding back a proper 1.2.4 release. So for reliable support, the safer bet would be to wait for 1.2.4; until then, it's under development and may break in weird ways. Regards, Nicos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wed, Jun 27, 2012 at 08:59:57AM +0200, Nicos Gollan wrote: Effectively, the standardisation process and related resolution of licensing issues for the new codec are one of the things holding back a proper 1.2.4 release. Whatever the real reasons for mumble upstream dragging its feet on making this easier for people to test may be, these aren't it. If they were real problems then Debian and its derivatives would not be shipping this, Fedora and Gentoo would not be shipping this, Firefox would not be shipping with support for this, gstreamer would not be shipping with support for this, mangler would not be shipping with support for this ... etc. etc. etc. And they especially would not be doing so with the encouragement and support of the developers from the CODEC working group and the holders of all relevant licences, who have been actively guiding and driving this rollout ... People with a much bigger stake in this than you have would be crying foul if there were even the smallest suspicion of such problems being real. Including myself. I'm even pretty sure you were around when this was discussed on IRC, so ... So for reliable support, the safer bet would be to wait for 1.2.4; until then, it's under development and may break in weird ways. Which is not to say this part might not be true. But only because of bugs that purely exist in mumble alone, not any other cause. I personally don't see how making it artificially hard for people to test it is going to make it stop breaking in weird ways any sooner ... but ymmv. Maybe people should look at the Mangler package and ventrilo if they really just want something that actually works today and they aren't concerned about the compromises they need to make to get that - which seems to be the ongoing theme here. They managed to get that working with opus in just a couple of days, and with none of the ED grade drama that we seem to be seeing here. Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 27, 2012 04:57:13, Ron wrote: On Wed, Jun 27, 2012 at 08:59:57AM +0200, Nicos Gollan wrote: ... So for reliable support, the safer bet would be to wait for 1.2.4; until then, it's under development and may break in weird ways. Which is not to say this part might not be true. But only because of bugs that purely exist in mumble alone, not any other cause. I personally don't see how making it artificially hard for people to test it is going to make it stop breaking in weird ways any sooner ... but ymmv. Maybe people should look at the Mangler package and ventrilo if they really just want something that actually works today and they aren't concerned about the compromises they need to make to get that - which seems to be the ongoing theme here. They managed to get that working with opus in just a couple of days, and with none of the ED grade drama that we seem to be seeing here. That cuts both ways. Okay... What do you believe the correct action to take for Mumble? What could you use help with? I've had a look at the mumble source package in git. On Sid, after doing a checkout of v1.2.3-348-g317f5a0-1 the package is not buildable right now because a dependency on libcelt-dev which has been removed. On Wheezy, after doing a checkout of v1.2.3-348-g317f5a0-1 I'm unable to get the package to build because there's no source tarball and debuild reports that it can't build source format 3.0 (quilt) if the source tarball is missing. Do you have the source tarball for 1.2.3-348-g317f5a0 at a web accessible location somewhere? -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 27, 2012 08:59:25, Chris Knadle wrote: ... On Wheezy, after doing a checkout of v1.2.3-348-g317f5a0-1 I'm unable to get the package to build because there's no source tarball and debuild reports that it can't build source format 3.0 (quilt) if the source tarball is missing. Do you have the source tarball for 1.2.3-348-g317f5a0 at a web accessible location somewhere? nevermind, 'apt-get source mumble' gets the necessary tarball. I've re-read what you had written to at least try to understand what options there there might be. If possible, I'd like some clarification on what the zero-ice snafu in the following statement means: On Tuesday, June 19, 2012 04:58:38, Ron wrote: ... Given the general state of things, including the zeroc-ice snafu of breaking ABI to fix the build with gcc 4.7, and the time we have remaining before the freeze, I'm having a very hard time seeing how this might possibly be a viable release candidate for Wheezy anyway at this stage. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Monday 25 June 2012 23:26:50 Chris Knadle wrote: It seems unusual to CC ftpmaster in a bug report, but keeping the CC as this is a reply to one that went there. I won't, there are people you definitely don't want to be on the bad side of ;-) On Sunday, June 24, 2012 21:36:28, Michael Schmitt wrote: A logical thing to try from here, if you want to give this a shot, would be to attempt to build the current upstream version from source and see if the current version of CELT that it includes will work with older versions of mumble-server, many of which are public. Mumble 1.2 will by default always only ship up to two versions of CELT: * 0.7.1 as a baseline, which is supposed to be supported by all clients and servers, and * a second, more recent version (for Mumble 1.2.4, that's 0.11, and that's unlikely to change since there won't be any further releases). Those two versions are incompatible, that's why the universally supported baseline is there. If you manage to get it to build and run, in the configuration select Advanced on the bottom left of the configure window, then in the Audio Output section under Loopback Test, try the server setting and see if you can hear yourself through the server. This would specifically be helpful in verifying firsthand if the newer versions of CELT that ship with upstream Mumble will work with older versions of mumble-server. The client tells the server which versions it supports. If it doesn't admit to supporting 0.7.1, the server will effectively assume that it does anyway, to retain a stable codec negotiation and to keep misbehaving clients from ruining things for everyone. That mechanism is supported by all 1.2 server versions (plus or minus a few details, but if you're on = 1.2.3, you should be golden; using 1.2.2 as a server, especially without a few patches, may not give you the stable operation you'd hope for). In a further step, the server makes sure to negotiate a codec that's supported by all clients within listening range. To my knowledge, that mechanism will work with all server versions that are not a stupid thing to use. The only thing new to the party is Opus, which requires further protocol support on the server side. So effectively, as long as your client advertises only codecs it really supports and has the baseline codec, server echo will work, as will communication with other people. 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). Do you know if CELT still the default codec? For the 1.2 series, it's supposed to be. Opus is going to be supported, it will be used if all clients support it, and there are knobs in place to make a server prefer it even at the disadvantage of older clients, but the baseline codec will be assumed for a long time to come. Hope that clears things up a bit, Nicos -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
Greetings Nicos. Thank you for your informative email. On Tuesday, June 26, 2012 09:08:45, Nicos Gollan wrote: On Monday 25 June 2012 23:26:50 Chris Knadle wrote: On Sunday, June 24, 2012 21:36:28, Michael Schmitt wrote: ... If you manage to get it to build and run, in the configuration select Advanced on the bottom left of the configure window, then in the Audio Output section under Loopback Test, try the server setting and see if you can hear yourself through the server. This would specifically be helpful in verifying firsthand if the newer versions of CELT that ship with upstream Mumble will work with older versions of mumble-server. The client tells the server which versions it supports. If it doesn't admit to supporting 0.7.1, the server will effectively assume that it does anyway, to retain a stable codec negotiation and to keep misbehaving clients from ruining things for everyone. That mechanism is supported by all 1.2 server versions (plus or minus a few details, but if you're on = 1.2.3, you should be golden; using 1.2.2 as a server, especially without a few patches, may not give you the stable operation you'd hope for). In a further step, the server makes sure to negotiate a codec that's supported by all clients within listening range. To my knowledge, that mechanism will work with all server versions that are not a stupid thing to use. The only thing new to the party is Opus, which requires further protocol support on the server side. So effectively, as long as your client advertises only codecs it really supports and has the baseline codec, server echo will work, as will communication with other people. I'm assuming all of the above is true under normal circumstnaces when CELT 0.7.1 support is included. However with libcelt0-0 removed, mumble version 1.2.3-349-g315b5f5-1 is unable to communicate via server loopback to the majority of the public mumble servers (at least in the United States) all of which seem to have versions = 1.2.3. None of the server loopback tests with public servers I tested with worked reliably. Tests shows that communication with this server works _sometimes_: 1.2.3-361-ga2a3836-ermine Server:0 FREE OrangeRed Mumble West 0 (Codec Opus) later retests fail and show Codec: None Tests failed with these servers: 1.2.3-1~ppa1~lucid Server:0- MumbleBoxes.com Demo Server - Atlanta #1 1.2.3-273-g0f4314e-ermine Server:0- FREE OrangeRed Mumble Central 0 1.2.3 (Win) 1.2.3 Server:Breakpoint Lobby 1.2.3-1ubuntu6.1Server:Luke's Server The intermittency of server loopback communication with the OrangeRed server above is interesting, and likely has to do with the protocol negotiation to find a protocol that all connected clients support. :-( Unfortunately I've come to the conclusion that with CELT 0.7.1 support removed, the user experience with public servers is dismal. Since CELT 0.7.1 support is assumed rather than advertised [based on what you've described], communication without support for it will be unreliable, at best. 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). Do you know if CELT still the default codec? For the 1.2 series, it's supposed to be. Opus is going to be supported, it will be used if all clients support it, and there are knobs in place to make a server prefer it even at the disadvantage of older clients, but the baseline codec will be assumed for a long time to come. Hope that clears things up a bit Yes, it does -- very much so. Thanks very much. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Sun, Jun 24, 2012 at 03:51:14PM -0400, Chris Knadle wrote: 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. The so called do nothing option is far simpler than that. The 348 version fails to build from source and so is undistributable. Since you insisted on reopening this bug as RC, it, among others, ties my hands and prevents updating that, and the actual logical conclusion is the people who preferred don't ship mumble in wheezy at all look like getting their wish now. If people would rather write long rationalisations about how to pretend the problem doesn't exist than Do Something to actually solve it and create a viable future for maintaining this code, than logically, that's probably even the correct outcome. To say I'm a bit disappointed by that would be an understatement, it certainly makes a waste of the effort I've put in trying to find some workable solution - but if nobody else cares enough than to say just close your eyes and ship it, then I don't see this being resolved in any adequate way in the tiny amount of time remaining to do so. A month ago you might have been able to convince me of anything if I saw people actually committed to Doing The Work needed to make that a viable answer. But all I've seen is people saying there is no problem until patches magically appear to fix it, and outright refusing to be the one who takes any responsibility for the now abandoned code. Now people are even saying they want other people to do double the work and take on all the risk, so that they (and innocent others) can be insecure without being interrupted from busily doing the nothing that they themselves would rather be doing. If the obvious answer to that isn't obvious, then I don't know what else to say. People I've never heard of are going to need better evidence than some dismissive handwaving to convince me to ignore the concerns of people who I very much trust. When the person who has found more bugs in this code than anyone else in the world expresses concern, it would be dumb not to listen to them - when someone who has never even looked at the code says I don't see a problem, then ... well ... I'm sure you can safely extrapolate from there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Monday, June 25, 2012 04:27:20, Ron wrote: On Sun, Jun 24, 2012 at 03:51:14PM -0400, Chris Knadle wrote: 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 see you've trimmed the last line from what I wrote, which fundamentally changes the meaning. The so called do nothing option is far simpler than that. The 348 version fails to build from source and so is undistributable. Since you insisted on reopening this bug as RC, it, among others, ties my hands and prevents updating that, and the actual logical conclusion is the people who preferred don't ship mumble in wheezy at all look like getting their wish now. What I /did/ was find a bug in the latest mumble client, found a bug report that matched the symtpoms but which was somehow closed without any explanation or fix, and reopened it. That was the correct action for me to take and if I hadn't done it someone else would have. If people would rather write long rationalisations about how to pretend the problem doesn't exist than Do Something to actually solve it and create a viable future for maintaining this code, than logically, that's probably even the correct outcome. I've already spent 12 hours testing several versions of both mumble-client and mumble-server on three platforms. This was intended to help both you and others. If this blame-laden email is your way of asking for further help, it's a piss poor way of doing it. I am willing to help further, but I'm most definitely not if you're going to continue giving me attitude. Learn to ask. Nicely. To say I'm a bit disappointed by that would be an understatement, it certainly makes a waste of the effort I've put in trying to find some workable solution - but if nobody else cares enough than to say just close your eyes and ship it, then I don't see this being resolved in any adequate way in the tiny amount of time remaining to do so. A month ago you might have been able to convince me of anything if I saw people actually committed to Doing The Work needed to make that a viable answer. But all I've seen is people saying there is no problem until patches magically appear to fix it, and outright refusing to be the one who takes any responsibility for the now abandoned code. Now people are even saying they want other people to do double the work and take on all the risk, so that they (and innocent others) can be insecure without being interrupted from busily doing the nothing that they themselves would rather be doing. I did not intend to suggest that packaging another version of mumble was correct for this case, but rather only that it has been done elsewhere and that it is up to the maintainer to choose the action to take. I felt this was necessary to explain to Michael because your reply to him was unhelpful to anyone, and I wanted to give him more helpful information. If the obvious answer to that isn't obvious, then I don't know what else to say. People I've never heard of are going to need better evidence than some dismissive handwaving to convince me to ignore the concerns of people who I very much trust. When the person who has found more bugs in this code than anyone else in the world expresses concern, it would be dumb not to listen to them - when someone who has never even looked at the code says I don't see a problem, then ... well ... I'm sure you can safely extrapolate from there. Right now the extrapolation I get is that trying to help you further is not a worthwhile use of my time. I'd appreciate it if that would change. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
It seems unusual to CC ftpmaster in a bug report, but keeping the CC as this is a reply to one that went there. On Sunday, June 24, 2012 21:36:28, Michael Schmitt wrote: Am 24.06.2012 21:51, schrieb Chris Knadle: On Saturday, June 23, 2012 15:54:07, Michael Schmitt wrote: .. 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. You're welcome. ... 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). Just to recap: Ron described communicating with upstream in which they did not commit to supporting CELT 0.7.1, which Ron said is bitstream incompatable with other versions of CELT. i.e. what is reported is that only a specific version of CELT is allegedly not getting support upstream. A logical thing to try from here, if you want to give this a shot, would be to attempt to build the current upstream version from source and see if the current version of CELT that it includes will work with older versions of mumble-server, many of which are public. If you manage to get it to build and run, in the configuration select Advanced on the bottom left of the configure window, then in the Audio Output section under Loopback Test, try the server setting and see if you can hear yourself through the server. This would specifically be helpful in verifying firsthand if the newer versions of CELT that ship with upstream Mumble will work with older versions of mumble-server. 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). Do you know if CELT still the default codec? -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
Hi tcwardr...@gmail.com, I confess I'm not entirely certain how to respond to this suggestion of yours ... If, on the one hand, you actually are a black-hat, who has put in the effort to actually analyse this for your own benefit - then I tip my hat to you and your art, and wish you all the best in your future endeavours. I'm sure it's quite evident that you'll find lots of low hanging fruit here, even if we don't plant a whole new orchard of it for you. If, on the other hand, you aren't, and haven't ... then, uh ... maybe we should discuss the other ... uh, opportunities ... open to you, like ... uh ... how about this one perhaps: I have many milleons of DOLLURS ($ many,000,000,000,000) LEGITAMITELY obtained from the vaults of Sadd@m that I wish to transfer to YOUR b * n k a c c * u n t. But we must do it with UT MOST SECR3CY. I am sure that you will understand this valuabl proposition for our mutial benerfit. We can let all users decide on their own if they want to be a part of this once in a lifetime bonanza, right? It's not like they'd blame us if all the extra work to put them at risk then blew up in their faces ... would they? On Sat, Jun 23, 2012 at 09:54:07PM +0200, tcwardr...@gmail.com 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. regards Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
I'm a bit dissappointed by the reply you got back to this suggestion, so I'm adding some thoughts concerning your idea. 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. 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. 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, because (IMHO) there isn't a clear path as to how to proceed here. 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, making both packages available would require going through the NEW queue at the last minute and would additionally risk being rejected. 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. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
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
Bug#675971: what should we be doing?
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. regards Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Thursday, June 21, 2012 00:57:23, Chris Knadle wrote: On Wednesday, June 20, 2012 08:20:39 PM Chris Knadle wrote: On Monday, June 18, 2012 22:59:40, micah anderson wrote: Is the situation that all users that are at 1.2.3-348 and older can speak to each other and all users that are at 1.2.3-349 and greater can speak to each other, but =349 cannot speak to =348 users? Additional testing. The newest client (349) in Debian without CELT support doesn't work with older versions of mumble-server in Debian -- but older versions of the client across several platforms seem to work with the newer versions of mumble-server in Debian. Notes: server 348 = 1.2.3-3480g317f5a0-1 in Debian 348 client includes libcelt0-0, mumble-server does not server 349 = 1.2.3-349-g315b5f5-1 in Debian client 361 = 1.2.3-361-ga2a3836 (Developer Snapshot for Windows) Yes means server loopback worked correctly (one user on server only) mumble Debian mumble-server versions client versions 1.2.2-6+squeeze1 1.2.3-2+b2 348 349 ---|--| Deb. Client 348 | Yes YesYes Yes | Deb. Client 349 |NoNoYes Yes | Win. Client 1.2.3a | Yes YesYes Yes | Win. Client 361 | Yes YesYes Yes | Mac Client 1.2.2 | Yes YesYes Yes | |--| I'm glad that newer versions of the server work with older versions of the client, and as such I no longer have a personal stake in the decision of whether Wheezy gets version 349 or not. The main issue I see is that the popular public mumble-server (murmur) servers seem to end up connecting using the CELT codec (which has issues) for which support for is removed in the 349 client in Debian Unstable (for good reasons). I don't personally use the public servers, but if 349 is shipped for Wheezy this will likely be frustraing for many, so at the least I suggest having a private repo around somewhere that contains version 348 to point people to if it becomes necessary. :-/ -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Monday, June 18, 2012 22:59:40, micah anderson wrote: Is the situation that all users that are at 1.2.3-348 and older can speak to each other and all users that are at 1.2.3-349 and greater can speak to each other, but =349 cannot speak to =348 users? I did some testing of Mumble Client/Server on versions in Debian to try to answer this. Notes: version 348 = 1.2.3-348-g317f5a0-1 348 client includes libcelt0-0, mumble-server does not version 349 = 1.2.3-349-g315b5f5-1 Yes means server loopback worked correctly (ONE user on server) Server 348Server 349 Server 1.2.3-2+b2 Client 348Yes Yes Yes Client 349Yes YesNo If so, is the intended plan for everyone to bump up to =349? Based on this very minimal testing, I think that would work. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
On Wednesday, June 20, 2012 08:20:39 PM Chris Knadle wrote: On Monday, June 18, 2012 22:59:40, micah anderson wrote: Is the situation that all users that are at 1.2.3-348 and older can speak to each other and all users that are at 1.2.3-349 and greater can speak to each other, but =349 cannot speak to =348 users? I did some testing of Mumble Client/Server on versions in Debian to try to answer this. Notes: version 348 = 1.2.3-348-g317f5a0-1 348 client includes libcelt0-0, mumble-server does not version 349 = 1.2.3-349-g315b5f5-1 Yes means server loopback worked correctly (ONE user on server) Server 348Server 349 Server 1.2.3-2+b2 Client 348Yes Yes Yes Client 349Yes YesNo If so, is the intended plan for everyone to bump up to =349? Based on this very minimal testing, I think that would work. ... however there's something else to consider -- version 349 is not available for all platforms. On the Mumble website (http://mumble.sourceforge.net) none of the platforms (including Linux) have that version advertised for it. From the appearance on the website, the latest Stable version advertised is 1.2.3a, and the Developer snapshot version is 361 (1.2.3-361-ga2a38360). -- -- Chris Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
Hi micah, On Mon, Jun 18, 2012 at 10:59:40PM -0400, micah anderson wrote: Is the situation that all users that are at 1.2.3-348 and older can speak to each other and all users that are at 1.2.3-349 and greater can speak to each other, but =349 cannot speak to =348 users? If so, is the intended plan for everyone to bump up to =349? If that is true, at the very least this warrants a NEWS entry. If only it were actually that simple ... The situation looks something like this: - Prior to the squeeze freeze, and after lots of discussion, mumble picked celt 0.7.1 to be the baseline codec for its internal protocol. It still had speex support then, but would prefer to use celt. - For squeeze we provided a system library of that, so that anything else which wanted to experiment with celt would have a version to do that with too. Thorvald was going to encourage other distros to ship this version of celt so there would be interoperability with a broad range of users - but that never happened and they all shipped some other incompatible version of it instead :( Mumble already embeds it's own celt for those. - For squeeze+1, we were fairly sure celt would be obsolete and we'd have Opus by now, and the plan was to drop the system lib when that happened, with mumble making celt a private library of its own (given that it's really the only thing that actually depends on 0.7.1). Eventually all of its users would have Opus and celt could be dropped there too. - We now have Opus, and all versions of celt outside of it are no longer being maintained by anybody. - Out best laid schemes then, true to form, gang aft agley when I learned of reasonable suspicion that 0.7.1 may be carrying a remote crasher among other unfixed issues. These things were fixed in later releases of celt, but given it's an experimental codec, those versions are neither bitstream compatible with 0.7.1, nor are those fixes directly backportable since much of the code has been entirely rewritten numerous times now. - 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. - Upstream has completely dropped the speex support from clients in recent changes to the code. So at the time of the -349 upload, this was supposed to be temporary, while people investigated the celt issues further. But since then, it's mostly become fairly clear that isn't going to happen in any particularly reassuring way, and people have in fact just reaffirmed that nobody actually wants to be responsible for maintaining celt 0.7.1. So I can't really in good faith sign off on pushing that to the distro for the life of a stable release at this point. Which means the mumble client that we currently have will only interoperate with clients that have opus support. Calling that an intended plan seems like an overstatement then ... For the moment, at best, it is Present Day Reality and full of very unintended elements. Given the cloud over celt 0.7.1, encouraging anyone you care about to update to a version using Opus instead seems independently prudent. Given the general state of things, including the zeroc-ice snafu of breaking ABI to fix the build with gcc 4.7, and the time we have remaining before the freeze, I'm having a very hard time seeing how this might possibly be a viable release candidate for Wheezy anyway at this stage. The only thing that seems to be clear, is that if mumble has a future, it's going to be with opus, not celt. So anybody who wants to help resolve this as quickly as possible, should definitely be focussing on that migration. This is largely out of my power to plan or control, so how long this will take pretty much entirely depends on how long it takes people to tell their friends it's time to update again. All I can really hope is that it will happen before the blackhats tell them that instead. All I can really do is not make that something Debian's -security team will need to deal with over the life of Wheezy. Sorry, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675971: what should we be doing?
Is the situation that all users that are at 1.2.3-348 and older can speak to each other and all users that are at 1.2.3-349 and greater can speak to each other, but =349 cannot speak to =348 users? If so, is the intended plan for everyone to bump up to =349? If that is true, at the very least this warrants a NEWS entry. micah -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
