On Friday, August 1, 2014 2:34:05 AM UTC-7, Stéphanie Ouillon wrote: > > If we're to support developer signing, we can imagine several models: > > 1) handling multiple signatures: the app is signed twice, once by the > developer and once by the Marketplace (e.g.: having two manifest files > in META-INF signed by each key) > > 2) the app is signed once by the developer key > > 3) the app is signed once by a developer key which is trusted and signed > by Mozilla >
I don't think the 3rd option is viable for process and possibly liability reasons(but IANAL). Mozilla would effectively have to implement a certain minimum degree of process as a certificate authority to verify developers' certificates. The 2nd option seems counter productive. The 1st option seems to be the most correct. I am uncertain how well the client side signature verification in b2g(or any other implementation) will handle multiple parallel signatures. Three rough todos I can think of off the top of my head: - Possibly need to modify the signing service to ignore existing .MF and .SF files in META-INF. I can't recall if it does this already - Tweak the Marketplace logic to verify that checksums of any existing manifests match what freshly generated checksums before signing with Marketplace cert. - Tweak the client verification code to find the signature file that uses the Mozilla Marketplace certificate and only verify those signatures. Alternatively: tweak the logic so that it validates all signatures it finds but fail if it doesn't find one that is issued by the hardcoded Marketplace cert. The work on the signing service side shouldn't be too extensive. I can't speak to the amount of effort necessary on the client side. --Ryan _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
