923256 - Enable JS symbol exporting in B2G

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[Michael Vines [:m1] [:evilmachines]]

+++ This bug was initially created as a clone of Bug #920731 +++

B2G partners make use of the XPCOM bundled extension facility, and some of these extensions rely on the JSAPI.  It would be lovely to get away from using the JSAPI but it's not feasible at the moment.  Please note that these are not at all the same as third-party add-ons in Firefox that bug 920731 was directed towards.  These bundled extensions that are burned into the commercial ROM like Gonk.

Comment 1

[Michael Vines [:m1] [:evilmachines]]

Attachment: a.patch

Comment 2

[Boris Zbarsky [:bzbarsky]]

> These bundled extensions that are burned into the commercial ROM like Gonk.

This is actually really incredibly scary.  It means that us shipping Gecko security fixes can break those extensions!

Furthermore, the chance that these extensions are using JSAPI correctly is vanishingly small.  Hard to confirm that without access to the source, of course...

> but it's not feasible at the moment.

Why not?  What can we do to get there?  I'd consider the current situation you describe a critical security bug....

Comment 3

[Michael Vines [:m1] [:evilmachines]]

(In reply to Boris Zbarsky [:bz] from comment #2)
> This is actually really incredibly scary.  It means that us shipping Gecko
> security fixes can break those extensions!

Gecko security fixes must go through the device manufacturer, Mozilla doesn't deploy Gecko updates independently to B2G devices.  Now that would be incredibly scary!

> > but it's not feasible at the moment.
> 
> Why not?  What can we do to get there?  

It is not a hard technical problem, just a time/resource issue.  This is effort that could, and should, be scheduled but at this point our tree is burning.  If this is something that Mozilla would like to disable for B2G we need some runway to de-JSAPI stuff first.  FxOS v1.3 would be an acceptable release to target.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> Gecko security fixes must go through the device manufacturer,

Yes, but are they auditing their JSAPI usage continuously against all those security fixes?

> we need some runway to de-JSAPI stuff first.

That seems reasonable, sure.  I'd just like us to make sure this actually happens.  Again, experience shows that any time someone writes JSAPI code it _will_ be buggy.  Usually exploitably so.

Comment 5

[Michael Vines [:m1] [:evilmachines]]

(In reply to Boris Zbarsky [:bz] from comment #4)
> > Gecko security fixes must go through the device manufacturer,
> 
> Yes, but are they auditing their JSAPI usage continuously against all those
> security fixes?

I seriously doubt it.  But this may be a larger discussion than this bug (yet is absolutely worthwhile having)!  


> > we need some runway to de-JSAPI stuff first.
> 
> That seems reasonable, sure.  I'd just like us to make sure this actually
> happens.  Again, experience shows that any time someone writes JSAPI code it
> _will_ be buggy.  Usually exploitably so.

How about this plan:
1) We fix this bug to get us green again.
2) I'll create a new bug to revert this bug.  It will be marked blocking-b2g:v1.3+ and I will be the assignee.
3) Once we remove the JSAPI dependencies over here, I'll fix the bug in #2.
4) If #3 doesn't happen soon enough, b2g-release-drivers will find the #2 bug due to it's blocking-b2g state and start harassing me.

Comment 6

[Boris Zbarsky [:bzbarsky]]

That plan sounds great.  Thank you!

Comment 7

[Luke Wagner [:luke]]

(Wow, I wasn't even aware of bug 920731, but that is fantastic to hear.)

Closed-source b2g binary extensions sound like a recipe for epic disasters, not just limited to JSAPI.  Are there mozilla people involved in auditing/advising the authors?

Comment 8

[Benjamin Smedberg]

Comment on attachment 813249 [details] [diff] [review]
a.patch

r=me for the temporary reversion to status-quo. The plan outlined here does seem important, to the point even of preventing any binary extensions including XPCOM.

Comment 9

[Michael Vines [:m1] [:evilmachines]]

Thanks.  It turns out that our exposure was pretty minimal, so we'll just make that change right away and short step comment 5.

We do plan to continue using binary XPCOM extensions in FxOS for the foreseeable future so I'd be more than happy to get on a call/vidyo sometime to discuss any concerns/etc.