Hi, First, I would like to know if this opinion apply to Gaia or not. There are various build config to modify resulting Gaia packages, and keyboard app already include layouts (which is JavaScript) and dictionary files selectively based on config given. With multiple form factors on the horizon, there will certainly be more creative build steps added to fit our needs.
Second, I don't understand how we are going to keep this security practice valid as an OS vendor. OEM and partners (e.g. QC) will certainly modify Gecko to fit their needs. We are making Gecko more secure in any way if we only tie our hands but allow partners to do whatever they want. On Mon, Dec 2, 2013 at 1:45 PM, Andreas Gal <andreas....@gmail.com> wrote: > > For security updates its critical to not develop a diverging zoo of Gecko > binaries. Originally we had one binary that was bit-for-bit identical on all > devices. We at some point reduced that constraint to binary-identical for all > devices with the same gonk version (ICS vs JB etc). Anything beyond that > should be detected by reading props the OEM can set. Please don't further > fork Gecko on a per-device basis. It would dramatically worsen our security > story. > > Thanks, > > Andreas > > On Dec 1, 2013, at 9:15 PM, Vicamo Yang <vic...@gmail.com> wrote: > >> Hi all, >> >> Recently we have a few bugs regarding the variety of features of different >> devices/platforms. See bug 920551 [1] and bug 939056 [2]. The problem is: >> shall we allow --disable-foo in per device configuration? >> >> Right now we have a file named 'default-gecko-config' inside gonk-misc/. >> The file contains 23 default |ac_add_options ...| lines and several of them >> are further controlled by environment variables exported in '.config' and/or >> '.userconfig'. >> >> Besides, there is also another way to inject such compile time options. The >> 'Android.mk' file in same gonk-misk/ directory suggests one may assign >> "GECKO_CONFIGURE_ARGS" in any other "Android.mk" files, and the value will >> be passed as "CONFIGURE_ARGS" env variable to Gecko during the configure >> stage. The best home for this variable is per device 'BoardConfig.mk' for >> sure. >> >> So back to the original problem: shall we allow --disable-foo in per device >> configuration? That is: shall we allow assigning "GECKO_CONFIGURE_ARGS" in >> per device 'BoardConfig.mk'? >> >> I would say YES. My 2 cents: >> >> 1) Code size. >> >> Back to bug 864485 [3], migrating Telephony IPC from frame messaging to >> IPDL, Telephony DOM code was then built on ALL platforms just like what we >> have for MobileMessage. By ALL, I mean it's compiled even on Windows. Then >> I got a regression mail saying the built binary size grew 1% after that >> patch on platforms didn't have WebTelephony before. Taking current >> /system/lib/libxul.so for example, 1% means 230KB. I heard there is some >> kind of delayed loading tech in use, but this still comes to my mind first >> when we were to built-in some dead code in final executables. >> >> 2) Runtime detection may lead to a certain problem. >> >> The two bugs, 920551 and 939056, are for enabling/disabling a certain B2G >> feature(s) on different devices. These features come with DOM APIs for >> sure. For now we're to hide APIs from user content when it's not available. >> Runtime detection is suggested but it takes time. It follows the first >> call to retrieve the availability of such feature should only be made after >> we're fully confident/determined there is no such feature on that device. >> For example, FTU need to know whether does the device implement RIL APIs or >> not before it's to display a menu item for "Import SIM contacts". Such >> calls have to be delayed after runtime detection is done, and again these >> detections take some time. Why not just skip these detections on devices >> that have no such feature at all? >> >> 3) How and why >> >> Till now, all devices have their own Gecko binaries. They're built directly >> from the source code and each of them is basically different from each >> other. No any devices share Gecko binaries at the time at all. Some >> devices have even additional patches to Gecko applied, and some replaces >> built-in components with their own. Mozilla just can't stop device makers >> from compiling Gecko by their own. And we just shouldn't do so, either. >> The thing we should only care is to provide unified Web API interfaces to >> users, not binary monopoly to device makers. >> >> So, what would you say? >> >> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=920551 >> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=939056 >> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=864485 >> _______________________________________________ >> dev-b2g mailing list >> dev-b2g@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-b2g > > _______________________________________________ > dev-b2g mailing list > dev-b2g@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-b2g -- Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox OS, Mozilla Corp. (Taiwan) _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
