[Go Faster] Default system add-ons and signing

Dave Townsend dtownsend at mozilla.com
Sat Sep 19 23:24:39 UTC 2015

On Fri, Sep 18, 2015 at 7:18 PM, Mike Connor <mconnor at mozilla.com> wrote:

> I'm not sure what you mean by " None of the rest of the Firefox code is
> signed so I don't know that we need to sign these other bits."
> Every binary is signed, and I thought we signed omni.ja, but seemingly not
> (I consider this a problem).

The binaries are signed in a way that prevents tampering? I'd not heard of

I mean there is nothing specific signing the chrome code that I know of, of
course the installers and mars that Firefox is delivered in are signed but
that doesn't help after installation.

> For local developer builds, are we going to default to enabling/requiring
> signing? I'd naively assume not, since we're not doing that in
> Nightly/Aurora.

Local developer builds require add-on signing. We could exempt local
developer builds from requiring just system add-ons to be signed, but that
still doesn't help the linux distro case or actually doing the release
builds any easier.

> On 18 September 2015 at 18:33, Dave Townsend <dtownsend at mozilla.com>
> 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.
>> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150919/78be0a19/attachment.html>

More information about the Gofaster mailing list