Prepare Firefox for Major-Minor Version upgrades

Registered by Alexander Sack on 2009-11-10

Mozilla moved to a monthly security update cycle early in 2009; next step planned is to stop doing stable release branches for any distro-relevant amount of time. For instance, they consider to release firefox 3.6 as a minor update to firefox 3.5 and want to a 3-4 month cycle for such minor-major version upgrades. Also it happens more frequently now that they bump reqtuirements on system libs like cairo and sqlite3 in minor version upgrades.

This is in line with what is planned by chromium and it's unfeasible to try to do our own stable release branch maintenance as this would require far more resources than we can get at any point in the future.

Instead we should prepare for what is coming and ensure that we can follow major-minor version upgrades in a timely fashion.

Main topics addressed by this blueprint are:

 1. how to prepare the firefox package so we can follow the major-minor version upgrade path.
 2. how to deal with xulrunner reverse-dependencies

Blueprint information

Status:
Complete
Approver:
Martin Pitt
Priority:
Essential
Drafter:
Alexander Sack
Direction:
Needs approval
Assignee:
Alexander Sack
Definition:
Approved
Series goal:
Accepted for lucid
Implementation:
Implemented
Milestone target:
None
Started by
Alexander Sack on 2010-01-18
Completed by
Jamie Strandboge on 2011-05-02

Whiteboard

doko 2010-03-16:
openjdk-6 in lucid now builds the IcedTeaNPPlugin using xulrunner-1.9.2. karmic would need a backport, but maybe consider backporting the openjdk-6 package itself (in a PPA?), after it's "certified" (passing the TCK).

rickspencer3 2010-02-11:
adding some tangentially related work items for Arne so I don't need to create a new blueprint.

pitti, 2009-12-10:
 - (future releases) I don't think it's beneficial to package extensions in a PPA; they will just break the same way when we upgrade firefox, and will presumably be even less maintained. Why not just use firefox' builtin plugin manager and drop all extensions (except some really compex ones like java)?
 - What is "AMO"?
 - (implementation background) the last sentence is cut off
[asac 18-01-10] landed the new all-in-one with minimal system depends packaging in firefox-3.5.head branch
[asac 29-01-10] first prioritization batch done on reverse deps wiki page: DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list
[asac 29-01-10] we will reuse the ffox35 porting ppa for this: https://launchpad.net/~mozillateam/+archive/ffox35

Work items (lucid-alpha-3):
drop system xulrunner dependency from build: DONE
drop most system libs from build, elminate existing patches accordingly: DONE
[ccheney] create reverse dependency package matrix for lucid: DONE
[ccheney] create reverse dependency package matrix for stable ubuntu releases: DONE
prioritize embedding reverse dependencies: DONE
prioritize embedding reverse dependencies in stable releases: DONE
identify reverse dependencies in stable releases that get exposed to insecure content: DONE
setup porting PPA: DONE
[jdstrand] update apparmor profile packaging to handle major version upgrades in karmic (and later): DONE
[jdstrand] update apparmor profile packaging to handle static build name transition: DONE
[arnegoetje] add support to ship localized searchplugins to langpack-o-matic: DONE
[arnegoetje] roll new langpacks to lucid with localized yahoo plugins that have a search code: DONE

work items (ubuntu-10.04-beta-1):
[chrisccoulson] identify extensions to be kept in archive - binary components or importance can qualify an extension: DONE

outwork items (not bound by lucid release cycle):
[asac] prepare firefox major version upgrade for stable release hardy: TODO
[asac] prepare firefox major version upgrade for stable release intrepid: TODO
[asac] prepare firefox major version upgrade for stable release jaunty: TODO
[asac] prepare firefox major version upgrade for stable release karmic: TODO
[ccheney] update reverse depending embedders exposed to remote/insecure content in hardy: TODO
[ccheney] update reverse depending embedders exposed to remote/insecure content in intrepid: TODO
[ccheney] update reverse depending embedders exposed to remote/insecure content in jaunty: TODO
[ccheney] update reverse depending embedders exposed to remote/insecure content in karmic: TODO
update identified key extensions for stable release hardy: TODO
update identified key extensions for stable release intrepid: TODO
update identified key extensions for stable release jaunty: TODO
update identified key extensions for stable release karmic: TODO
prepare updated translations for major version upgrade in hardy: TODO
prepare updated translations for major version upgrade in intrepid: TODO
prepare updated translations for major version upgrade in jaunty: TODO
prepare updated translations for major version upgrade in karmic: TODO
work with QA and security team on testplan major version upgrade to stable releases: TODO
roll out stable release updates: TODO
post mortem for major version upgrades: TODO

2009-11-10 (micahg):
I think we should have 2 things here.
1. The firefox source package (main) which will have Firefox+xul so that we can migrate to whatever new releases we need without impacting other software.
   a. We would need to decide when to jump to the next version. Options are:
       1. When Mozilla pushes the Major Update
       2. When current version is EOL
2. A separate xulrunner source package (universe) that will be up to date with the release and get security fixes for as long as possible.

Background:
 * most CVEs in the archive
 *

History:
 * Mozilla has kept stable release branch upgraded (security and major fixes)
 * typical: 40 CVEs, 120 fixes per microrelease
 * promise of 6 months support for previous stable after a new release; after that we did backports ourselves
 * Hardy: upstream support for 3.0 will end in December
 * even though we follow the upstream review policy, we get much less QA
 * once an LTS is released, it is hard to get testers for previous LTSes
 * Chromium: no stable support at all, rolling upgrades for all users; Mozilla seems to like that
 * Plan: Major version upgrades every 4 to 6 months, no support for previous stable at all any more

Pushing new major versions into stables:
 * packaged and user-installed addons will just stop working
 * Hardy QA wrt. other rdepends

we will need to get our extensions repackaged for each major release, every few weeks
 - extensions for the new version may take weeks to come out
 -> or remove the packages from the archive (except our own ones)
 * do not want to use upstream binaries. lose gnome (VFS, Printing, ...) integration, LP integration, compiler hardening

Take as granted:
 * back porting security fixes will no longer be sustainable
 * we will not be able to change mozilla policy

What we would need to do:
 * stop using system libraries, use bundled ones (which will double CVE tracking and exposures in these libraries, but work won't be significantly increased for these libraries -- the work will be shared potentially with firefox upstream)
 * drop xulrunner to universe, resolve remaining rdepends
 * 3rd party addons may go away from the archive for lucid; for stables: find an install.rdf hack which we ship in -updates which will cause firefox treat it as it was in the profile, and use the builtin auto-update feature
 * moving away from Firefox as default browser is considered a bad user experience and not really feasible for lucid (rendering still not as good as ffox)

Problem with openjdk - firefox 3.6 is dropping the required API support for openjdk's browser plugin. If we release Firefox 3.6 for Karmic, we'll break everyone using openjdk as a browser plugin.

Alex' s3kr1t plan for Lucid and forward:
 * drop xul runner, don't build against xul runner, ship what upstream is shipping
  * important rdepends which we can't just remove: couchdb, eclipse, yelp
 * ship without patches
 * ship with bundled library
 * no third parties releases
 * open JDK? can we upgrade to it, or we will have to remove it and have Sun Java
 * Do we plan to firefox
 * Put sun java in partner archive

current stable releases:
 * do the same for firefox, as long as a version is supported, we force upgrades across stable releases
 * find rdepends that are exposed to web content
 * ship the firefox with the non-system libraries
 * epiphany: push to karmic version to use webkit backend

translations plan:
 * import the new upstream XPIs manually into rosetta
 * don't build new languages
 * put them into langpack-o-matic
 * either update -base package OR
 * generally don't ship ffox translations in -base, just in updates (one-time transition for stable Ubuntus)

Thunderbird:
 * most CVEs are not an issue, since JavaScript is disabled
 * does not need a similarly extreme thing, few remaining patches can be backported

How do we maintain this going forward
 * should discuss with QA team how to support on major version upgrades early (while can still file bugs)
 *

 ACTIONS:
 * start fixing the package to start building everything in ff without patches
 * same source package for all stable releases
 * figure out upgrade path for packaged extensions in stables
 * create a security native PPA for the ff non-patched builds
 * review xulrunner rdepends from hardy on which apps are potentially exposed to insecure contents
  * switch to gtkhtml or webkit
  * confine with apparmor
  * ignore if they don't use javascript
 * define who does what after the transition (ie security updates)
 * rickspencer3 to schedule weekly call

List of xulrunner rdepends:

https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list

Status:
lucid: firefox 3.6 in archive; xulrunner 1.9.2 pending upload; porting started

(?)

Work Items