[Go Faster] Default system add-ons and signing

Ben Hearsum bhearsum at mozilla.com
Mon Sep 21 15:30:53 UTC 2015

On Sun, Sep 20, 2015 at 10:23:28AM +0200, Axel Hecht wrote:
> On 9/19/15 12:33 AM, Dave Townsend wrote:
> >At the moment the plan is to include the most recent versions of any
> >system add-ons with Firefox at build time. We're also expecting all system
> >add-ons to be signed by a special signing root. These two things don't
> >work out so well together. Unless we check in signed versions of system
> >add-ons whenever they change then developers doing local builds won't be
> >able to run the system add-ons, also we'll have to figure out some way for
> >releng builds to sign the add-ons before packaging the app. The problems
> >are larger for linux distros doing their own builds. None of that sounds
> >good.
> >
> >Instead I propose that we don't require the system add-ons that ship with
> >the app to be signed (the updates that download mid-cycle would still be
> >signed of course). None of the rest of the Firefox code is signed so I
> >don't know that we need to sign these other bits. We do still want to make
> >it difficult for malicious apps to use this as a means to inject code into
> >Firefox. The current client code assumes these system add-ons just live as
> >XPIs in a directory in the installation directory and any new XPI dropped
> >in would be used by Firefox (unless we've already downloaded some new
> >system add-ons mid-cycle). If we're concerns that that is too easy a
> >target there are a couple of options we could use:
> >
> >One option is to instead embed the system add-ons inside omni.ja. *This
> >probably has some nice performance wins* as it is but it means that in
> >order to inject a new system add-on in an attacker must alter omni.ja, and
> >if they're willing to do that then they can just turn off the signing
> >requirements or even just edit browser.js already anyway.
> >
> Highlight mine.
> The mere possibility that we'll get perf wins here to me is a reason to not
> go down the omni.ja route. If that was the case, we'd ship a perf regression
> to our release audience every first update-after-update.

To flesh this out a bit more, I _think_ you're implying that mid-cycle system addon updates won't end up in omni.ja. I think that's probably a safe assumption, because putting them into omni.ja would end up screwing up partial MAR updates for the next Firefox version.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150921/8cf183cf/attachment.sig>

More information about the Gofaster mailing list