[Go Faster] Default system add-ons and signing

Axel Hecht axel at mozilla.com
Sun Sep 20 08:23:28 UTC 2015

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.
We'd also have no perf testing on this in our standard testing 
infrastructure, as that's testing the builds we produce.
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.

(update-after-update means the first add-on update after a firefox 
update. no idea if we have a term for that)

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

> _______________________________________________
> Gofaster mailing list
> Gofaster at mozilla.org
> https://mail.mozilla.org/listinfo/gofaster

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150920/b22e091c/attachment.html>

More information about the Gofaster mailing list