When deciding whether to apply an update,some important things to know are:
1. Should I download a new JAR? 2. Is the new JAR the "same app" as the app I am trying to update? 3. Is the new JAR a *newer* version of that app? 4. Is the server that is serving the JAR giving us the information that the marketplace app/website expects it to? Regarding #1, I agree with Jonas (on an earlier private thread) that using normal HTTP conditional requests is good enough. If we download a JAR and find out that it is a bad version (older than what is installed) or the wrong app, then we can just show an error and throw it away. That would never happen if the server is functioning normally and it would just mean a wasted download; as ling as we do checks #2 and #3, it should be OK. #2 is important so that nobody can trick the web server into asking the user to replace one app with another (unrelated) app that the marketplace has signed. #3 is important to prevent downgrade attacks. For #2 an #3, we need to have some way, given two JAR files, and no other information, to decide whether those two JAR files are the same app and that one is newer than the other. It seems like these two pieces of information are currently missing. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=814136 for implementing these checks (#2 and #3). Regarding #4: Basically, this is when a hash of the contents of the JAR would be useful to include in the mini-manifest. This would improve security in the case that the marketplace server is on a trusted web server, but the app JARs themselves are served off of a less-trusted CDN. If we do #2 and #3, then it will only be possible for the less-trusted CDN to give us a newer version of the same app than what is currently installed. But, while it may be *newer*, it may not be the *newest*. If we also verify that a hash in the mini-manifest matches the hash of the JAR, then the less-trusted CDN will only be able to give us the *newest*. But, this assumes that the mini-manifests are served from a highly-trusted server (not the CDN). If the manifests are to be served off the less-trusted CDN, then the mini-manifests themselves should be signed similarly to the JARs themselves. One reason it is important to ensure we have the *newest* version (not just a newer version) is because we will handle app revocation by distributing an update to the app. As far as priorities are concerned, I would say that doing them in the order above (#1 first, #4 last) makes a lot of sense. However, we should also decide which of these four additional verifications are blockers, if any. For example, if we don't use a less-trusted CDN to server apps then #4 is not very useful. Cheers, Brian _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
