Steps to reproduce: Call navigator.mozApps.installPackage with a manifest that will fail (it can be a manifest that points to an incorrectly signed app or even worse, a manifest for a correctly signed app that's *already* installed). What should happen: An error should be shown and the apps database (webapps.json) should NOT be modified. What happens: An error is shown but the database IS updated. When it's called with an already installed app that means the webapps.json gets two entries (or three, four... depends on how persistent you are trying to install it) with the same manifest. The database gets into an inconsistent state. The only way I've found to restore it is to 1. Delete the app, 2. Reboot the phone, 3. Rinse and repeat as many times as failed install tries for that app exist on the database (you can delete just one try per reboot).

I'm noming this because I believe packaged apps is part of V1, and we cannot ship this as is. navigator.mozApps.installPackage isn't even a privileged app, and it's quite easy to trick the user into getting his app database inconsistent (much easier than restoring it in fact). Note that the user can lose access to an app he's installed (and paid for on the worst case) this way. First install: the app gets installed. Second install: the app is broken.

Basecamp nom time is gone. Use tef? for noms now with tracking-b2g?

Do you have the patch from bug 827502 applied?

(In reply to Fabrice Desré [:fabrice] from comment #3) > Do you have the patch from bug 827502 applied? I think so... I built it this morning with the latest from the firefox 18 branch. Let me verify it though.

(In reply to Antonio Manuel Amaya Calvo from comment #4) > (In reply to Fabrice Desré [:fabrice] from comment #3) > > Do you have the patch from bug 827502 applied? > > I think so... I built it this morning with the latest from the firefox 18 > branch. Let me verify it though. Yep, I have it. It doesn't let it on half delete state... it adds another instance of the same app that never gets installed. In fact some times I can get the app working again without reinstalling it (just by deleting the app/rebooting, see if I get the correct one otherwise delete/reboot).

Can you point to a test page? I can't reproduce that with the "Packaged App" from http://owapps.cloudfoundry.com/. We get a download error because of a manifest mismatch, but reinstalling doesn't leave us in an inconsistent state.

(In reply to Fabrice Desré [:fabrice] from comment #6) > Can you point to a test page? I can't reproduce that with the "Packaged App" > from http://owapps.cloudfoundry.com/. We get a download error because of a > manifest mismatch, but reinstalling doesn't leave us in an inconsistent > state. I've been trying it with signed apps, dunno if it makes any difference or not. It fails both when the install isn't successful/shouldn't be successful (because the store isn't authorized, or because the install-from-allowed doesn't include the site) and when the install should be successful (correct signature from a correct URL store). I've been trying it with https://sigsegv.es/store but for it to work you'll have to add some certificates to your database and modify the store preferences so you can install from that URL. With the correct certificate and config, the first time I hit install it succeeds. The second and succesive it just adds new apps to the webapps.json. Let me know if you want me to add as attachments here the cert9, key4, and user.js files I'm using.

This file contains a .bat and .sh that push to the device a certificate database and settings to allow the install of signed apps from https://sigsegv.es/store

Ok, I've tried and it seems that the app being signed makes some difference. With the apps from http://owapps.cloudfoundry.com/ I get a half installed app but only one instance of it on the database even after several failed tries. With the signed app though I can install it successfully on the first call to installPackage and then the second call to installPackage creates another entry on webapps.json. It fails also when I try to download an incorrect app (signature is correct but the store isn't allowed). I also get this on the logcat: I/GeckoDump( 107): XXX FIXME : Got a mozContentEvent: webapps-install-granted I/Gecko ( 107): RemoteOpenFileParent: file '/data/local/webapps/{3a6f5490-e504-4d1b-bae7-d0c9f9ee767c}/application.zip' was not found! I/Gecko ( 370): RemoteOpenFileChild: file was not opened! I/Gecko ( 107): RemoteOpenFileParent: file '/data/local/webapps/{3a6f5490-e504-4d1b-bae7-d0c9f9ee767c}/application.zip' was not found! I/Gecko ( 370): RemoteOpenFileChild: file was not opened!

Interesting. This has actually nothing to do with signed apps, but is because of the install URL: sigsegv.es/store sends install url like : https:sigsegv.es/store/packages/importer.webapp. While valid, this was causing issues when resolving relative urls. The patch sanitize the manifest URL as soon as possible, which fixes the issue.

(In reply to Fabrice Desré [:fabrice] from comment #10) > Created attachment 701403 [details] [diff] [review] > patch > > Interesting. This has actually nothing to do with signed apps, but is > because of the install URL: sigsegv.es/store sends install url like : > https:sigsegv.es/store/packages/importer.webapp. While valid, this was > causing issues when resolving relative urls. Thanks Fabrice! :) While I'm glad to have catch this even by blunder, it would have been less embarrassing had I found it by design instead of by forgetting to add the // when composing the URL :P

Sorry, removed the block by error.

(In reply to Antonio Manuel Amaya Calvo from comment #8) > Created attachment 701386 [details] > Certificate database and script to push it > > This file contains a .bat and .sh that push to the device a certificate > database and settings to allow the install of signed apps from > https://sigsegv.es/store See also https://github.com/briansmith/marketplace-certs/

(In reply to Brian Smith (:bsmith) from comment #13) > (In reply to Antonio Manuel Amaya Calvo from comment #8) > > Created attachment 701386 [details] > > Certificate database and script to push it > > > > This file contains a .bat and .sh that push to the device a certificate > > database and settings to allow the install of signed apps from > > https://sigsegv.es/store > > See also https://github.com/briansmith/marketplace-certs/ Small derailing... Do the change_trusted_servers.sh work for you? Besides not stopping b2g before modifying the prefs file... I could never get a change in that file to stick. Whenever I change it it changes back when the process restart. That's why I ended modifying the /system/b2g/defaults/pref/user.js file instead.

(In reply to Antonio Manuel Amaya Calvo from comment #14) > Do the change_trusted_servers.sh work for you? Besides not stopping b2g > before modifying the prefs file... I could never get a change in that file > to stick. Whenever I change it it changes back when the process restart. > That's why I ended modifying the /system/b2g/defaults/pref/user.js file > instead. I did test it out and it worked. But I only tried a couple of times; it is possible I just got lucky in winning some race. I do see how why it is at best unreliable. AFAICT, it would be better to modify my scripts to kill b2g before the modifications are done and then restart it after the modifications are done.

(In reply to Brian Smith (:bsmith) from comment #15) > (In reply to Antonio Manuel Amaya Calvo from comment #14) > > Do the change_trusted_servers.sh work for you? Besides not stopping b2g > > before modifying the prefs file... I could never get a change in that file > > to stick. Whenever I change it it changes back when the process restart. > > That's why I ended modifying the /system/b2g/defaults/pref/user.js file > > instead. > > I did test it out and it worked. But I only tried a couple of times; it is > possible I just got lucky in winning some race. I do see how why it is at > best unreliable. AFAICT, it would be better to modify my scripts to kill b2g > before the modifications are done and then restart it after the > modifications are done. Strange. I was stopping the process and even so when the process started again the changes on that file were sent to the changes heaven. I'll have to check that again, thanks.

Comment on attachment 701403 [details] [diff] [review] patch Review of attachment 701403 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/apps/src/Webapps.js @@ +76,5 @@ > + let uri; > + try { > + uri = Services.io.newURI(aURL, null, null); > + let scheme = uri.scheme; > + if (scheme != "http" && scheme != "https") { Is it possible to use |nsIURI.schemeIs()| instead. Or do we want to make the check case-sensitive?

https://hg.mozilla.org/integration/mozilla-inbound/rev/2c7287304555 https://hg.mozilla.org/releases/mozilla-b2g18/rev/154833a84517

backed out of inbound due to test failures (a bunch of mochitest-oth timing out) https://hg.mozilla.org/integration/mozilla-inbound/rev/d94202f46627

note, I don't have a b2g18 report at hand, please take care of that.

Relanded with tests passing: https://hg.mozilla.org/integration/mozilla-inbound/rev/acecf63268be https://hg.mozilla.org/releases/mozilla-b2g18/rev/221bedb0ad2d

(In reply to Fabrice Desré [:fabrice] from comment #22) > Relanded with tests passing: > https://hg.mozilla.org/integration/mozilla-inbound/rev/acecf63268be > https://hg.mozilla.org/releases/mozilla-b2g18/rev/221bedb0ad2d Or not. Still failing on b2g18. Backed out. https://hg.mozilla.org/releases/mozilla-b2g18/rev/4c66309f7ba1

Still failing on inbound, backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/cf77e6413213

Try run at: https://tbpl.mozilla.org/?tree=Try&rev=41ab77768978 Looks good expect the perma-orange

Landed on mozilla-b2g18/gaia master prior to the 1/25 branching to mozilla-b2g18_v1_0_0/v1.0.0, updating status-b2g-v1.0.0 to fixed.