Re: Switching to mozilla ESR in stable-security
Christoph Anton Mitterer cales...@scientia.net schrieb: --=-dGSWlplfgLb+HUgDia6J Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Moritz. Moritz Muehlenhoff wrote: In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. Form a security POV, I think this is really quite dangerous... actually tendency should go towards the direction that users install plugins addons only via the package management system. These plug-in systems which come with their own package/installation management are IMHO also quite bad from a philosophical POV... I mean they try to replace the traditional package management system, which is there and superior for very good reasons. Of course this doesn't mean that I wouldn't see the problem you face with keeping that stuff running and security supported. In think in the future providing the xul extensions through the Debian Developer repositories provided by the FTP masters would be the most elegant way: There's a one month overlap between ESR and ESR++, so there's sufficient time to prepare/test extensions before the ESR++ hits users. However, we don't currently have these repositories, so addons.mozilla.org is the best we have for now. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqm2a4.4u1@inutil.org
Re: Switching to mozilla ESR in stable-security
Didier 'OdyX' Raboud o...@debian.org schrieb: FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up [0] maintaining some of the most security-sensitive softwares up to our stable policy, why should other packages be bound to it? - having a web browser in the distro is crucial and $random-other-app-to-buggy-to-support isn't - Mike has done a terrific job of backporting security fixes (up to 100 security patches per month!), but modern web browsers expose a unique environment on their own. Even if we backport security fixes (and we cannot continue any longer since the resources are not there anymore!) we still miss out important security enhancements (e.g. lenny-security missed CSP support). Not to mention the fast-moving browser requirements, which are not security related (e.g. HTML, WebGL). - The policy we're following is the intended update policy for enterprise envionments (e.g. Ubuntu updates to the current upstream release even in their oldest supported distro) - The ESR releases shipped by Mozilla receive more QA testing than we could possibly provide for our backports. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqm1v1.4u1@inutil.org
Re: Switching to mozilla ESR in stable-security
On 06/02/2013 01:35 AM, Florian Weimer wrote: I'm not sure if moving packages between repositories makes that much of a difference. Either they work acceptably well, or they don't, independently of the delivery mechanism. The main difference would be that we accept the fact that Mozilla software aren't suitable to stay in the stable Debian, and that we declare that they can only be sustainable through a repository that has recent updates. Backports seems a way to me, though volatile maybe as well, IMO. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ab0ab6.90...@debian.org
Re: Switching to mozilla ESR in stable-security
On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Would it be possible to switch to the Mozilla branding in this case? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
Ansgar Burchardt ans...@debian.org schrieb: Hi, On 05/28/2013 22:33, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Reverse-deps of the older xulrunner libs have negligable security impact and we won't update them any further. One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. As mentioned on IRC, I wonder what we should do with these extentions now and for future releases. There seem to be several options: a) Remove most Mozilla extensions from stable/testing/unstable and let users install them from addons.mozilla.org. Important addons could stay if agreed with release and/or security teams, e.g. enigmail (mentioned above) or adblock (part of the default Debian GNOME installation). b) Let maintainers update extensions via either -security or -(proposed-)updates. This causes additional work for the security team or the release team for at least coordinating updates. I wouldn't expect them to be able to review the changes which means a break from our current stable policy. b2) like b), but only do so for jessie and remove the extensions from testing/unstable. c) Let maintainers provide updated extensions via an additional repository (e.g. mozilla.d.n or some developer repository). (c) is my prefered way to move forward. We'll release enigmail in sync with icedove once icedove is ready. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqm3qr.8tn@inutil.org
Re: Switching to mozilla ESR in stable-security
On Sun, Jun 02, 2013 at 12:10:56PM +0300, Andrei POPESCU wrote: On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Would it be possible to switch to the Mozilla branding in this case? I suspect not, since we are likely still going to apply the 40 patches that we currently apply. Also, such a major change is likely to break things in a security upload. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
Andrei POPESCU andreimpope...@gmail.com schrieb: --Yvzb+MHGXtbPBi5F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Ma, 28 mai 13, 22:33:03, Moritz Muehlenhoff wrote: =20 As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security.=20 Would it be possible to switch to the Mozilla branding in this case? No, that is unrelated. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqmitk.5sd@inutil.org
Re: Switching to mozilla ESR in stable-security
On Sun, Jun 02, 2013 at 05:04:54PM +0800, Thomas Goirand wrote: On 06/02/2013 01:35 AM, Florian Weimer wrote: I'm not sure if moving packages between repositories makes that much of a difference. Either they work acceptably well, or they don't, independently of the delivery mechanism. The main difference would be that we accept the fact that Mozilla software aren't suitable to stay in the stable Debian, and that we declare that they can only be sustainable through a repository that has recent updates. Backports seems a way to me, though volatile maybe as well, IMO. Apparently it takes long to die/bury, but volatile as a separate thing does not exist (anymore). It was replaced by a speedy way to bring updates to stable users instead of an overlay with a different update policy. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On 05/28/2013 04:33 PM, Moritz Muehlenhoff wrote: Hi, we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. One thing to be careful of in this regard: The Firefox developers are intentionally dropping some features from the main browser, for one reason or another. As far as I recall none have been dropped yet, but several are in the pipeline. Leaving aside any debate about whether this is a reasonable thing to do, it means that moving from one ESR major release version to the next may result in potentially significant functionality change - which, AFAIK, is something we try to avoid with package updates in a stable release. I don't have a problem with packaging the ESR in general, and if a given ESR major release is in stable, I think it makes sense to ship the associated minor/micro releases as security updates for stable as they come out (since security fixes is generally what they are). Transitioning between ESR major release versions, however, may well warrant more care. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51ac0e23.3090...@fastmail.fm
Re: Switching to mozilla ESR in stable-security
On 2013-05-31 08:52:37 +, Raphael Geissert wrote: Russ Allbery rra at debian.org writes: [...] This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. Packages which, by the way, are not supported by the security team. Is it important? Doesn't upstream (here, Mozilla) do a good job concerning security? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130601112400.ga10...@xvii.vinc17.org
Re: Switching to mozilla ESR in stable-security
Am Donnerstag, den 30.05.2013, 22:29 +0100 schrieb Wookey: +++ Josh Triplett [2013-05-29 11:50 -0700]: Moritz Muehlenhoff wrote: One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. I find it much easier to install those via the Debian packaging system rather than a user-level mechanism that involves running Firefox as one or more target users (or more likely doing the equivalent of creating a xul-ext-* package for local use). I realize that you can't maintain the full library of Firefox addons as packages, but I'm hoping that some of the most common and popular ones stick around and stay up to date, notably Adblock Plus, HTTPS Everywhere, and It's All Text. Absolutely, and I'd like to add lazarus, noscript, ghostery, user-agent switcher, and debian-buttons to that list of 'can't-live-without, worth maintaining as packages' add-ons. (And Tab Mix Plus is exceedingly handy too) Obviously if no-one wants to maintain them then I guess we'll have to get them the way everyone else does, but I certainly find real value in having them packaged, and am pleased every time I can get an add-on that way. Do we have helpers (as for CPAN and similar archives) to make creation and maintenance of such packages simple? mozilla-devscript is the helper to create xul-ext packages. It helps installing the .xpi file in the right place and creates the dependency lists. We have a wiki page [1] with a usage explanation. PS: It would be good to have this wiki page content converted to a man page that we could ship with the mozilla-devscript package. Help doing this would be appreciated. [1] http://wiki.debian.org/mozilla-devscripts If it wasn't too hard I'd be happy to maintain xul-ext-lazarus, for example. It is simple in most cases. You often just repack the .xpi file. Do you mean Lazarus: Form Recovery with xul-ext-lazarus [my first connection was the Lazarus IDE for Pascal]? This extension is labeled as Freeware and therefore not DFSG-free. You have to convince upstream to relicense the package before it can enter the main archive. I don't think that it makes sense to packaging non-free xul extensions in the Debian archive. -- Benjamin Drung Debian Ubuntu Developer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1370094430.3020.14.camel@deep-thought
Re: Switching to mozilla ESR in stable-security
* Thomas Goirand: Maybe the best way forward is to have backports activated by default (there's already a patch available for that, not sure if it has been applied to d-i yet). Then when installing a desktop (since backports are now fully part of Debian), we could provide browsers from there (maybe as a Recommends:, so it isn't forced into our users ?). I'm not sure if moving packages between repositories makes that much of a difference. Either they work acceptably well, or they don't, independently of the delivery mechanism. From what I see, the main pain comes from packages which are complex, without long-term support from upstream for the version we use, and which are used as a reverse dependency by other packages. Of those, only the latter part seems to be something over which we have some degree of control, that is, we could make sure that these packages are more or less leaf packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip1xlon7@mid.deneb.enyo.de
Re: Switching to mozilla ESR in stable-security
Russ Allbery r...@debian.org (30/05/2013): Jonas Smedegaard d...@jones.dk writes: Sorry, what bugreport? I do not consider backports.debian.org of same quality as debian.org so am concerned by what you outline above, and would like to (at the least) read up on the relevant discussion (i.e. avoid rehashing it here). I'm afraid I've expired the backports-users message that contained the bug number, but I believe it was a bug report against debian-installer, since that's the place the change was requested. #691651 Mraw, KiBi. signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
Russ Allbery rra at debian.org writes: [...] This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. Packages which, by the way, are not supported by the security team. Curiously enough, that's the subject that triggered this thread. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130531t105043-...@post.gmane.org
Re: Switching to mozilla ESR in stable-security
Quoting Russ Allbery (2013-05-30 19:56:23) Wouter Verhelst wou...@debian.org writes: On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. Two issues keep getting confused when people talk about this, so let me try to clarify the way that this was clarified on backport-users. The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. If you mean bug#691651 as Cyril suggests (thanks, Cyril!) then I only see that bugreport talking about adding commented out line for backports. Not relying on APT hints for damage control. Can someone elaborate on those plans? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Switching to mozilla ESR in stable-security
Hi, Josh Triplett wrote (29 May 2013 18:50:23 GMT) : As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. FTR, packaged XUL extensions make it easier to build Debian Live systems, too. In any case, thanks for considering switching to ESR! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/857gihc6c6@boum.org
Re: Switching to mozilla ESR in stable-security
Le jeudi, 30 mai 2013 00.10:11, Philip Hands a écrit : Moritz Mühlenhoff j...@inutil.org writes: Willi Mann foss...@wm1.at schrieb: Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more extensions to be updated. We need to release the security updates when ready and cannot realistically align the point releases with Mozilla releases. Does this perhaps indicate that these packages are not really suitable for stable, and should instead be provided via backports or some similar mechanism (i.e. a mozilla-bikeshed[1])? I concur. Although I very much understand the practical constraints leading to softening the no new upstream versions in stable policy for the specific case of browsers, it nevertheless feels as jumping on the no stability exists outside of the latest upstream releases bandwagon. If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? OdyX signature.asc Description: This is a digitally signed message part.
Re: Switching to mozilla ESR in stable-security
* Didier Raboud: If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? Which web browsers would remain in stable if we applied this criterion consistently? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5awljc7@mid.deneb.enyo.de
Re: Switching to mozilla ESR in stable-security
Le jeudi, 30 mai 2013 14.53:44, Florian Weimer a écrit : * Didier Raboud: If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201305301520.29815.o...@debian.org
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. And one we should tackle, IMHO, but that's for a separate discussion. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530132922.gb6...@upsilon.cc
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 8:53 PM, Florian Weimer wrote: Which web browsers would remain in stable if we applied this criterion consistently? The best browser ever; lynx. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gvmdr8pzydemdwyh69c-96cox7hxt-msyx_9-vop-...@mail.gmail.com
Re: Switching to mozilla ESR in stable-security
On 2013-05-29 20:50, Josh Triplett wrote: As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. I find it much easier to install those via the Debian packaging system rather than a user-level mechanism that involves running Firefox as one or more target users (or more likely doing the equivalent of creating a xul-ext-* package for local use). I realize that you can't maintain the full library of Firefox addons as packages, but I'm hoping that some of the most common and popular ones stick around and stay up to date, notably Adblock Plus, HTTPS Everywhere, and It's All Text. It was pointed out to me that Chrome supports policy definitions[1] where administrators can force certain extensions to be installed[2] and up-to-date. Now it might or might not make sense for packages to simply ship such a policy file, but at least it would provide a way for the administrator to have the same result. But I guess the Mozilla family does not support this yet? Kind regards Philipp Kern [1] http://www.chromium.org/administrators/policy-list-3 [2] /www.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0c705a399566a8ebb190a9ba2f5f2...@hub.kern.lc
Re: Switching to mozilla ESR in stable-security
Hi Moritz. Moritz Muehlenhoff wrote: In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. Form a security POV, I think this is really quite dangerous... actually tendency should go towards the direction that users install plugins addons only via the package management system. These plug-in systems which come with their own package/installation management are IMHO also quite bad from a philosophical POV... I mean they try to replace the traditional package management system, which is there and superior for very good reasons. Of course this doesn't mean that I wouldn't see the problem you face with keeping that stuff running and security supported. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Switching to mozilla ESR in stable-security
On 05/30/2013 09:29 PM, Stefano Zacchiroli wrote: On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. I agree with both Zack and Didier here. Maybe the best way forward is to have backports activated by default (there's already a patch available for that, not sure if it has been applied to d-i yet). Then when installing a desktop (since backports are now fully part of Debian), we could provide browsers from there (maybe as a Recommends:, so it isn't forced into our users ?). Thoughts? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78c69.40...@debian.org
Re: Switching to mozilla ESR in stable-security
On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78ffd.9020...@debian.org
Re: Switching to mozilla ESR in stable-security
Wouter Verhelst wou...@debian.org writes: On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. Two issues keep getting confused when people talk about this, so let me try to clarify the way that this was clarified on backport-users. The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. I think this is an excellent idea and is absolutely something we should do. backports.debian.org helps considerably in easing the pain of our long release cycle but is underadvertised. This would make using it much simpler and more straightforward for our users. What would be giving up on doing stable releases is to install software from backports by default (in other words, remove NotAutomatic). No one is proposing that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqqgz708@windlord.stanford.edu
Re: Switching to mozilla ESR in stable-security
On Thursday, May 30, 2013 10:56:23 AM Russ Allbery wrote: Wouter Verhelst wou...@debian.org writes: On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. Two issues keep getting confused when people talk about this, so let me try to clarify the way that this was clarified on backport-users. The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. I think this is an excellent idea and is absolutely something we should do. backports.debian.org helps considerably in easing the pain of our long release cycle but is underadvertised. This would make using it much simpler and more straightforward for our users. Agreed. FWIW, Ubuntu has done this with their backports repositories for the last two years of releases and it seems to be working well (exactly as you suggest it will for Debian). Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3060684.Mtj6vbfRpJ@scott-latitude-e6320
Re: Switching to mozilla ESR in stable-security
Le jeudi, 30 mai 2013 15.29:22, Stefano Zacchiroli a écrit : On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? No, not unless we'd provide said browsers in a different suite (hence the bikeshed proposal). That would make the difference in applied security polices clearer, IMHO. FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up [0] maintaining some of the most security-sensitive softwares up to our stable policy, why should other packages be bound to it? Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. The problem is equally worrying for both free and non-free extensions IMHO. Christoph worded it better than I could [1]. And one we should tackle, IMHO, but that's for a separate discussion. I'm not sure it's that much of a separate discussion: as the original message mentionned, we'll get the ESR17 and then ESR24 version of Firefox/Iceweasel in Wheezy, including the new features related to extensions and 3rd party repositories, which are out of our control. I must admit though that I don't know precisely how this area evolves and I do trust the Maintainers of Mozilla-related packages to do it right. Cheers, OdyX [0] And that's _definitely_ not meant as fingerpointing anyone. [1] 1369924284.5345.7.ca...@fermat.scientia.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201305302029.16610.o...@debian.org
Re: Switching to mozilla ESR in stable-security
Quoting Russ Allbery (2013-05-30 19:56:23) Wouter Verhelst wou...@debian.org writes: On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. Two issues keep getting confused when people talk about this, so let me try to clarify the way that this was clarified on backport-users. The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. Sorry, what bugreport? I do not consider backports.debian.org of same quality as debian.org so am concerned by what you outline above, and would like to (at the least) read up on the relevant discussion (i.e. avoid rehashing it here). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 10:56:23AM -0700, Russ Allbery wrote: The actual proposal in the bug report is to add backports.debian.org to the default sources.list file in the installer, but not otherwise change anything about the backports configuration. Specifically, the archive would remain NotAutomatic ButAutomaticUpgrades. This would *enable* users to install software from backports if it either didn't exist in stable at all or if they explicitly requested it from backports, but would not install such software by default. I think this is an excellent idea and is absolutely something we should do. backports.debian.org helps considerably in easing the pain of our long release cycle but is underadvertised. This would make using it much simpler and more straightforward for our users. FWIW, I concur. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 08:29:16PM +0200, Didier 'OdyX' Raboud wrote: FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. That compromise (which I do definitely support for wheezy) puzzles me most for the precedent it creates: if we give up [0] maintaining some of the most security-sensitive softwares up to our stable policy, why should other packages be bound to it? Well, it seems to me that the decision chain is pretty clear here. The we you've used above is IMHO defined as the security team. It's them doing the amazing security job they do for Debian, therefore it's perfectly fine for them to decide where and when to make compromises. Other packages will be bound or not to similar compromises depending on the judgement of the security team. Note that it's already the case that the level of security support for packages in stable varies on a case by case basis, see for instance: http://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security *By default* everything it's held up to the same security standards, but we do apply different policies when needed, as decided by the security team. What's important is to clearly communicate to our users what they're getting. Sometime we can do that in advance, as above, in other occasion we might have to do it a posteriori. That's life. (And I suspect that, given an unlimited supply of manpower, the security team will be happy to do all the backports we needed. Unfortunately we simply don't have that supply.) Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. […] And one we should tackle, IMHO, but that's for a separate discussion. I'm not sure it's that much of a separate discussion: as the original message mentionned, we'll get the ESR17 and then ESR24 version of Firefox/Iceweasel in Wheezy, including the new features related to extensions and 3rd party repositories, which are out of our control. I must admit though that I don't know precisely how this area evolves and I do trust the Maintainers of Mozilla-related packages to do it right. You're right, I've been unclear. What I meant is this: whether the 3rd party repositories that come configured with our browsers list non-free extensions by default or not (which is a change I would welcome) is a separate discussion. The existence of those 3rd party repositories, no matter the free-ness of the extensions, clearly is impacted by our security policy decisions. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
Jonas Smedegaard d...@jones.dk writes: Sorry, what bugreport? I do not consider backports.debian.org of same quality as debian.org so am concerned by what you outline above, and would like to (at the least) read up on the relevant discussion (i.e. avoid rehashing it here). I'm afraid I've expired the backports-users message that contained the bug number, but I believe it was a bug report against debian-installer, since that's the place the change was requested. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txlkxnfp@windlord.stanford.edu
Re: Switching to mozilla ESR in stable-security
On 05/30/2013 08:06 PM, Scott Kitterman wrote: FWIW, Ubuntu has done this with their backports repositories for the last two years of releases debian-live images have this by default since squeeze too. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a7ad51.5000...@progress-technologies.net
Re: Switching to mozilla ESR in stable-security
+++ Josh Triplett [2013-05-29 11:50 -0700]: Moritz Muehlenhoff wrote: One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. I find it much easier to install those via the Debian packaging system rather than a user-level mechanism that involves running Firefox as one or more target users (or more likely doing the equivalent of creating a xul-ext-* package for local use). I realize that you can't maintain the full library of Firefox addons as packages, but I'm hoping that some of the most common and popular ones stick around and stay up to date, notably Adblock Plus, HTTPS Everywhere, and It's All Text. Absolutely, and I'd like to add lazarus, noscript, ghostery, user-agent switcher, and debian-buttons to that list of 'can't-live-without, worth maintaining as packages' add-ons. (And Tab Mix Plus is exceedingly handy too) Obviously if no-one wants to maintain them then I guess we'll have to get them the way everyone else does, but I certainly find real value in having them packaged, and am pleased every time I can get an add-on that way. Do we have helpers (as for CPAN and similar archives) to make creation and maintenance of such packages simple? I'd assume they were amenable to this approach, but am entirely unfamiliar with the issues involved with keeping them synced with browsers. If it wasn't too hard I'd be happy to maintain xul-ext-lazarus, for example. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530212940.gb14...@stoneboat.aleph1.co.uk
Re: Switching to mozilla ESR in stable-security
On 29/05/13 00:17, John Paul Adrian Glaubitz wrote: Also, if anyone of the GNOME package maintainers is reading this, why does the gnome meta package depend on xul-ext-adblock-plus? For feature parity with the previous meta-gnome3 web browser, it appears: meta-gnome3 (1:3.4+3) unstable; urgency=low ... * Install iceweasel instead of epiphany :( See bug#682481. * Let gnome recommend iceweasel-l10n-all. * Drop RSS readers recommendations. * Require firefox extensions that match epiphany functionality: keyring, adblock. ... -- Josselin Mouette j...@debian.org Sat, 29 Sep 2012 10:36:58 +0200 Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5a54c.9070...@debian.org
Re: Switching to mozilla ESR in stable-security
On Tue, May 28, 2013 at 10:33:03PM +0200, Moritz Muehlenhoff wrote: Hi, we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. and iceape. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529070659.ga18...@glandium.org
Re: Switching to mozilla ESR in stable-security
Hi, On 05/28/2013 22:33, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Reverse-deps of the older xulrunner libs have negligable security impact and we won't update them any further. One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. As mentioned on IRC, I wonder what we should do with these extentions now and for future releases. There seem to be several options: a) Remove most Mozilla extensions from stable/testing/unstable and let users install them from addons.mozilla.org. Important addons could stay if agreed with release and/or security teams, e.g. enigmail (mentioned above) or adblock (part of the default Debian GNOME installation). b) Let maintainers update extensions via either -security or -(proposed-)updates. This causes additional work for the security team or the release team for at least coordinating updates. I wouldn't expect them to be able to review the changes which means a break from our current stable policy. b2) like b), but only do so for jessie and remove the extensions from testing/unstable. c) Let maintainers provide updated extensions via an additional repository (e.g. mozilla.d.n or some developer repository). I would expect some more packages giving us similar problems in the future: other web browsers (chromium) or web applications (owncloud?) where we might have to provide new upstream versions that require updating related packages (or breaking them). With my user hat on, I would like to have (b) though I'm not sure how much work it would be. I don't like (c). It's too similar to (b) with a workflow easy enough for the release/security team. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a5ff74.6060...@debian.org
Re: Switching to mozilla ESR in stable-security
On 29.05.2013 15:15, Ansgar Burchardt wrote: I would expect some more packages giving us similar problems in the future: other web browsers (chromium) or web applications (owncloud?) where we might have to provide new upstream versions that require updating related packages (or breaking them). + MySQL (in particular). There the situation is very complicated, too thanks to Oracle. I don't know if this applies to other Oracle products, too think of Virtualbox etc. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Switching to mozilla ESR in stable-security
Hello Moritz, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more extensions to be updated. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will Enigmail is definitly requiring an update for ESR 17 in wheezy. When should I have a package ready and where should I upload it? Greetings, WM -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ko5de0$243$1...@ger.gmane.org
Re: Switching to mozilla ESR in stable-security
Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Very welcome news. One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. I find it much easier to install those via the Debian packaging system rather than a user-level mechanism that involves running Firefox as one or more target users (or more likely doing the equivalent of creating a xul-ext-* package for local use). I realize that you can't maintain the full library of Firefox addons as packages, but I'm hoping that some of the most common and popular ones stick around and stay up to date, notably Adblock Plus, HTTPS Everywhere, and It's All Text. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529185021.GA9742@jtriplet-mobl1
Re: Switching to mozilla ESR in stable-security
Arno Töll a...@debian.org schrieb: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enigD8B4E48BF27B74A11F1ECB8F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29.05.2013 15:15, Ansgar Burchardt wrote: I would expect some more packages giving us similar problems in the future: other web browsers (chromium) or web applications (owncloud?) where we might have to provide new upstream versions that require updating related packages (or breaking them). + MySQL (in particular). MySQL isn't comparable. While the horribly disclosure policy of Oracle forces us to update to new upstream releases, there are no additional packages dependant on MySQL version bumps. Plus, the 5.1.x and 5.5.x series are maintained far longer than a Firefox ESR series. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqcmco.4vj@inutil.org
Re: Switching to mozilla ESR in stable-security
Willi Mann foss...@wm1.at schrieb: Hello Moritz, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more extensions to be updated. We need to release the security updates when ready and cannot realistically align the point releases with Mozilla releases. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will Enigmail is definitly requiring an update for ESR 17 in wheezy. When should I have a package ready and where should I upload it? We'll deal with Iceweasel first. We'll let you know when an icedove package is ready. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqcm8o.4vj@inutil.org
Re: Switching to mozilla ESR in stable-security
Moritz Mühlenhoff j...@inutil.org writes: Willi Mann foss...@wm1.at schrieb: Hello Moritz, Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more extensions to be updated. We need to release the security updates when ready and cannot realistically align the point releases with Mozilla releases. Does this perhaps indicate that these packages are not really suitable for stable, and should instead be provided via backports or some similar mechanism (i.e. a mozilla-bikeshed[1])? Cheers, Phil. [1] http://lists.debian.org/debian-devel/2013/05/msg00481.html -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpihrR2A2XTF.pgp Description: PGP signature
Switching to mozilla ESR in stable-security
Hi, we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Reverse-deps of the older xulrunner libs have negligable security impact and we won't update them any further. One problematic aspect are the various xul-ext-* packages currently packaged. It's very likely that some of them will break with ESR17 and ESR24 in the future. However, there's not much we can do here. We can select a narrow (!) set of important addons (e.g. enigmail for Icedove) that we will keep in sync through stable-security, but that doesn't scale for the full scale of Mozilla extensions currently packaged. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. If you maintain an extension, you can test the compatibility with the packages already available at http://people.debian.org/~jmm/ Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130528203303.GA5425@pisco.westfalen.local
Re: Switching to mozilla ESR in stable-security
Hi Moritz! On 05/28/2013 10:33 PM, Moritz Muehlenhoff wrote: we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. I second this. Having one of the most commonly used desktop applications lacking so much behind the current upstream versions in a newly released Debian version is very frustrating and annoying. Having the current ESR versions of Iceweael and Icedove in Debian stable is the best practice as these releases were just intended to be used in scenarios were Debian stable is deployed. As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. Great! Really looking forward. Let me add to that there is currently no easy way (e.g. without rebuilding the package) to install Icedove ESR on Wheezy. The Debian Mozilla packaging team suggests installing Icedove ESR from unstable [1], but alas this version is linked against libc6 2.17 and will therefore force an update of the libc6 installed on Wheezy which is unacceptable [2]. I therefore urge anyone involved in packaging Icedove to provide a version of Icedove ESR linked against the version of libc6 in Wheezy. Also, if anyone of the GNOME package maintainers is reading this, why does the gnome meta package depend on xul-ext-adblock-plus? This often causes major headache when upgrading either Iceweasel or Icedove in the form that using the wrong upgrade path will result in partial or full removal of GNOME. In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. I think this is the best approach. Most addons should be installed through the built-in addon manager as this will make keeping addons up-to-date much easier and reduces maintaining efforts. As long as we're going with the latest ESR versions, I assume that most of the most popular addons will work when installed through the official upstream sources. Cheers, Adrian [1] http://mozilla.debian.net/ [2] http://paste.debian.net/7192/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a53af2.3010...@physik.fu-berlin.de
Re: Switching to mozilla ESR in stable-security
On Wed, May 29, 2013 at 4:33 AM, Moritz Muehlenhoff wrote: we need to change the way security fixes are handled for Mozilla in stable-security. The backporting of security fixes is no longer sustainable resource-wise. Please propose an announcement about this to the Debian press team and add a paragraph about it to DPN (all DDs have commit access). https://wiki.debian.org/ProjectNews/HowToContribute -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6h0tuj08nhvomaa8sunr4axbganu2xfi_goscnvofh...@mail.gmail.com
