[Go Faster] Default system add-ons and signing

Mike Connor mconnor at mozilla.com
Sat Sep 19 02:18:06 UTC 2015


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

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.

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/20150918/1bb2dd15/attachment.html>


More information about the Gofaster mailing list