Re: Switching to mozilla ESR in stable-security

[John Paul Adrian Glaubitz]

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

[Paul Wise]

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

Re: Switching to mozilla ESR in stable-security

[Simon McVittie]

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   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

[Mike Hommey]

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

[Ansgar Burchardt]

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

[Arno Töll]

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

[Willi Mann]

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

[Josh Triplett]

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

[Moritz Mühlenhoff]

Arno Töll  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

[Moritz Mühlenhoff]

Willi Mann  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

[Philip Hands]

Moritz Mühlenhoff  writes:

> Willi Mann  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

Re: Switching to mozilla ESR in stable-security

[intrigeri]

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

[Didier 'OdyX' Raboud]

Le jeudi, 30 mai 2013 00.10:11, Philip Hands a écrit :
> Moritz Mühlenhoff  writes:
> > Willi Mann  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

[Florian Weimer]

* 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

[Didier 'OdyX' Raboud]

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

[Stefano Zacchiroli]

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

[Paul Wise]

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

[Philipp Kern]

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

[Christoph Anton Mitterer]

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

[Thomas Goirand]

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

[Wouter Verhelst]

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

[Russ Allbery]

Wouter Verhelst  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)   


-- 
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

[Scott Kitterman]

On Thursday, May 30, 2013 10:56:23 AM Russ Allbery wrote:
> Wouter Verhelst  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

[Didier 'OdyX' Raboud]

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

[Jonas Smedegaard]

Quoting Russ Allbery (2013-05-30 19:56:23)
> Wouter Verhelst  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

[Stefano Zacchiroli]

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

[Stefano Zacchiroli]

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

[Russ Allbery]

Jonas Smedegaard  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)   


-- 
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

[Daniel Baumann]

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

[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? 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

[Cyril Brulebois]

Russ Allbery  (30/05/2013):
> Jonas Smedegaard  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

[Raphael Geissert]

Russ Allbery  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

[Jonas Smedegaard]

Quoting Russ Allbery (2013-05-30 19:56:23)
> Wouter Verhelst  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

[Vincent Lefevre]

On 2013-05-31 08:52:37 +, Raphael Geissert wrote:
> Russ Allbery  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  - Web: 
100% accessible validated (X)HTML - 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

[Benjamin Drung]

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

[Florian Weimer]

* 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

[Moritz Mühlenhoff]

Christoph Anton Mitterer  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

[Moritz Mühlenhoff]

Didier 'OdyX' Raboud  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

[Thomas Goirand]

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

[Andrei POPESCU]

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

[Moritz Mühlenhoff]

Ansgar Burchardt  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

[brian m. carlson]

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

[Moritz Mühlenhoff]

Andrei POPESCU  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

[Philipp Kern]

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

[The Wanderer]

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