836859 - Trying download an update for the maps packaged app fails with INVALID_SIGNATURE

Status: VERIFIED FIXED

(Core Graveyard :: DOM: Apps, defect)

Description

[Jason Smith [:jsmith]]

Build: 1/31
Device: Unagi

Steps:

1. Try to download the update for the maps packaged app

Expected:

The update should complete successfully.

Actual:

The update fails with INVALID_SIGNATURE.

Comment 1

[Jason Smith [:jsmith]]

There's a separate problem with the fact that the download failing is putting the app in a bad state (doesn't remain launchable). I thought that was fixed, but apparently not (or it wasn't uplifted).

Comment 2

[Jason Smith [:jsmith]]

Talking with Fabrice, client side appears to be operating normally. Maybe a signing server bug? Ryan?

Comment 3

[Jason Smith [:jsmith]]

Platform code looks okay. Reading it as I understand, we always require the app to be signed when pulling from a trusted store. Nothing showing up on the marketplace side. Maybe a out of date certdb issue?

Comment 4

[Jason Smith [:jsmith]]

Well...I just tried doing a simple packaged app update off of marketplace with two signed apps and did not see a problem.

So what's so special about the maps app that's causing it to fail?

Comment 5

[Jason Smith [:jsmith]]

Fabrice confirmed this is a gecko issue:

	fabrice	gecko issue, where we pick up the package path in the current manifest instead of the new staged update manifest
	fabrice	and the maps app is the only one that changes that path for now

Comment 6

[[:fabrice] Fabrice Desré]

Attachment: patch

The patch itself is not interesting, but the cause is:

- we were not setting the installState when installing 3rd party apps.
- in startDownload, installState == undefined, so isUpdate = false. At this point, we re-use the old manifest instead of the staged one, and consider that we are trying to re-download the installation package.
- in the case of the maps app, the initial package uri is bogus (it's http://marketplace.firefox.com/application.zip). But we open an http channel and download this 404 page, try to open it as a zip and to compute a signature. That fails.
- lastly, since we though that we were retrying an initial download, we set the installState to "pending", which prevent the app to be launched again.

The patch sets installState for 3rd party preinstalled apps, and also protects against http errors when we download a package.

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 708859 [details] [diff] [review]
patch

Review of attachment 708859 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks Fabrice. Looks good. r=me

::: dom/apps/src/Webapps.jsm
@@ +2117,5 @@
>  
> +          // If we get a 4XX or a 5XX http status, bail out like if we had a
> +          // network error.
> +          let responseStatus = requestChannel.responseStatus;
> +          if (responseStatus >= 400 && responseStatus <= 599) {

nit: we could use the above condition:

if (!Components.isSuccessCode(aStatusCode) ||
    (responseStatus >= 400 && responseStatus <= 599)) {
  ...
}

Comment 8

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/mozilla-inbound/rev/dfc06d96fa34

Comment 10

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/dfc06d96fa34

Comment 11

[[:fabrice] Fabrice Desré]

Comment on attachment 708859 [details] [diff] [review]
patch

[Approval Request Comment]
Another defense in depth / better error management patch. No risk there.

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Definitely want this, marking tef+ and will clear the approval nomination.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/d8dad1530a3b
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_0/rev/af0e6726fd8a

Comment 14

[Jason Smith [:jsmith]]

Verified on b2g18 2/6/2013.