On Fri, Sep 21, 2012 at 12:44 PM, Andy McKay <[email protected]> wrote: > > On 20/09/2012, at 6:22 PM, Jonas Sicking wrote: >> What makes you think that we're not using a signed jar format? I don't >> know exactly what the signature format looks like as I don't have >> enough crypto chops, but I'm pretty sure we're trying to make it as >> standard as possible. > > A signing format for packaged apps hasn't been defined yet and I'm hoping we > can get that sorted out soon. I'm keen on using an existing structure we have > already as much as possible. Similar to what exists for App receipts or Addon > signing.
Two things: 1) I think you've missed one of the main points of my alternative proposal above: by using standard SSL to authenticate online installation, no code signing is needed in the common case, nor is there any special format or tool needed for 90% of the use cases. This includes web stores: the web-consistent way to do this is to serve apps from subdomains of the web store, for example: https://twitter.my-appstore.us/manifest.webapp https://twitter.my-appstore.us/resources.zip (of course resources.zip could be unpacked as well, since it's just a handy shorthand for stuffing an appcache). This uses the existing SSL trust hierarchy (and a wildcard cert) for my-appstore.us to clearly indicate that my-appstore.us trusts this particular version of the app. No other code signing or verification is needed. The app store can handle multiple versions in whatever way it likes, leaving this open for 3rd parties to innovate. The most recent version might always be served, or if some people would prefer not to immediately update, it might serve apps from (for example): https://v1.twitter.my-appstore.us/ or some similar scheme. THIS EXPOSES THE VERSION IN THE URI which is the way the web works. You could do redirections if you wanted twitter.my-appstore.us to stand for the latest version, etc. This builds on existing web mechanisms. Note that this proposal works well with existing CORS support as well: twitter.com (or whatever) would use Access-Control-Allow-Origin: https://twitter.my-appstore.us/ to indicate that the app sold by my-appstore.us was allowed to use its resources. (If you're not using an appstore, then an SSL certificate for https://mywebapp.com is sufficient proof that the contents of https://mywebapp.com/mainfest.webapp and https://mywebapp.com/resources.zip are good/maintain integrity/etc.) 2) Signing a zip would be necessary for off-line verification *only*, ie someone hands you a USB stick with a zip file on it and you want to ensure that it's a trusted app. The existing XPI signing mechanism is not such a great example here, since it's not standardized and no one other than mozilla uses it, and it's rather cumbersome (read https://developer.mozilla.org/en-US/docs/Signing_a_XPI if you don't believe me). What's more, for security purposes the offline signature mechanism should really use exactly the same chain of trust as the standard installation mechanism in (1) -- ie, it's a signature which says that the person who controls https://twitter.my-appstore.us has certified this .zip bundle as being identical to what was served from https://twitter.my-appstore.us/resources.zip at some point in time. (One odd consequence is that this is *not* a "code signing certificate" it's a normal domain certificate -- which is substantially more convenient for developers to obtain.) Jar files have a much larger installed base, and already used (for example) with slight variation in the apk package format and the security chain of trust has been worked out for java web start, etc. (They typically use code signing certificates, though.) --scott -- ( http://cscott.net ) _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
