[Go Faster] Default system add-ons and signing

Dave Townsend dtownsend at mozilla.com
Wed Sep 23 15:45:28 UTC 2015


On Mon, Sep 21, 2015 at 8:30 AM, Ben Hearsum <bhearsum at mozilla.com> wrote:

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

Yes, mid-cycle updates go in the profile (and would be signed) regardless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150923/c7ff301c/attachment.html>


More information about the Gofaster mailing list