[Go Faster] Default system add-ons and signing

Dave Townsend dtownsend at mozilla.com
Wed Sep 23 15:50:54 UTC 2015

On Sun, Sep 20, 2015 at 1:23 AM, Axel Hecht <axel at mozilla.com> 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.

So to be clear you're advocating making every build slower, not just the
builds that have received mid-cycle updates? The main performance
difference here only affects the first run after a Firefox update, other
runs probably would have wins but until we had a lot of code in system
add-ons I don't think it would be measurable.

> We'd also have no perf testing on this in our standard testing
> infrastructure, as that's testing the builds we produce.

The system add-ons are in the builds we produce so why wouldn't be have

> And there'd be hardly any pre-release audience testing the code path and
> perf characteristics of our release audience (well, at least not after the
> first update-after-update). 'Cause our nightly audience will only ever be
> on bundled versions, so will aurora. Same might still hold true for Beta.

I'm not sure that's true for aurora, maybe though.

> An even simpler option is to leave the XPIs where they are but include a
> file listing the expected add-ons and maybe their hashes in omni.ja. Again
> attackers would have to manipulate omni.ja to have any effect, it would be
> a simpler attack but it would also be much much simpler to implement this
> option.
> Any concerns or other ideas for this? How much protection do we feel we
> need to put in place around the default system add-ons?
> I have an additional question: How do these proposals map to
> aurora/beta/release builds?

Other channels behave the same as nightly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150923/a961dd5e/attachment.html>

More information about the Gofaster mailing list