When webapps.json is created on Gaia, all apps are given "appStatus": 3 meaning they're certified Apps. Then when you install that profile on the phone and restart it for the first time (or you run B2G desktop on a newly created profile), the system automatically adds the permissions by calling PermissionsInstaller.installPermissions. What happens: PermissionsInstaller.installPermissions use the manifest "type" attribute to determine whether it should add a requested permission as allow or deny, not the appStatus from webapps.json. And the appStatus from webapps.json isn't updated (and it's the field actually used about everywhere else to determine the security level of an app). So as a result we have an app that is marked as 'certified' on the apps database (webapps.json) but that has been granted permissions as a 'installed' app. What should happen: Decide what field is going to be the authoritative one. Either apply the permissions as indicated by webapps.json appStatus (can just add/update manifest.type based on appStatus on Webapps.jsm to avoid having to modify the PermissionsInstaller logic), or update appStatus based on the manifest.type if the app is already installed. Either way you should get a consistent permissions/appStatus state. As it stands now, you can get an appStatus certified app that gets granted permissions as a installed app.
All the gaia apps have "type" : "certified" in their manifest. See for example https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/manifest.webapp#L5 I think we're fine here.
(In reply to Fabrice Desré [:fabrice] from comment #1) > All the gaia apps have "type" : "certified" in their manifest. See for > example > https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/manifest. > webapp#L5 > > I think we're fine here. Ah, should we close this then?
All the current apps have type: certified... But trusting on manually keeping integrity isn't a good practice usually. I lost a lot of time yesterday because of this: I was testing an app that didn't had the type attribute because it had an old version of the manifest. And I was relying on what webapps.json said (that it was indeed) certified and didn't understand why it wasn't working. That is, didn't understand it until I checked what PermissionInstaller was actually doing. TL; DR: I think the integrity should be kept automatically not manually
Carmen, these are *preloaded* apps. If you don't trust what's in gaia, especially the build system, well... The field in the manifest is the one that is used at install time to decide the status of the app, which then ends up in webapps.json. If you fail at keeping them in sync while not going through a real installation path, this is not really a gecko bug in my view.
(In reply to Fabrice Desré [:fabrice] from comment #4) > Carmen, these are *preloaded* apps. If you don't trust what's in gaia, > especially the build system, well... Well, she works in security, I don't think she trusts her shadow that much either :P > > The field in the manifest is the one that is used at install time to decide > the status of the app, which then ends up in webapps.json. If you fail at > keeping them in sync while not going through a real installation path, this > is not really a gecko bug in my view. Hmm that's not correct. Check https://github.com/mozilla-b2g/gaia/blob/master/build/webapp-manifests.js#L43 the appStatus is hardcoded to 3. Well, except for the ones on the external-apps directory that are saved without a appStatus and thus are assigned an appStatus of 1 sometime during the initial load. I was torn between putting this as a Gaia build bug or as a platform bug. But I still think that no matter how the fields (manifest.type and webapps.json.appStatus) are filled, the system that uses them (that is gecko) should be the one responsible of keeping the system integrity. Anyway, if you feel this should be a Gaia build bug, we can file it there.