I want to correct and clarify a few details in my tome on XPI files, and add a few missing details. I wrote:
> The XPI specification allows only one "signature block" file (that is, > .rsa or .dsa) per JAR, and requires that it be the first file in the > zipped JAR. That's not exactly right. XPI files aren't forbidden to have multiple signature block files. But the first file in the zipped XPI must be a signature block file (a .rsa or .dsa file), and that first file is the only file examined for a valid signature. Since an XPI file is a JAR file, it may contain other signature block files, and each of them may effectively sign its own subset of the files in the JAR. The subsets may be overlapping, (meaning that there can be multiple signers for a file or set of files in the JAR), and nothing prevents the zip file that contains the signed JAR from also containing files that are not signed by any of the signature blocks in the JAR. This means that an application (such as a JAR file installer, or browser) that relies on the validity of one (or more) signature(s) in the JAR must ensure that it only processes the files in the zip/jar/xpi whose signatures & hashes have been validated, and must not blindly treat the entire contents of the zip/jar/xpi as if all the files were signed, merely because one (or more) of them was signed. When different signature block files exist in the META-INF directory, they have different names, but the same filename extension (e.g. .dsa or .rsa). For each such signature block file, there are a number of related files in the META-INF directory that have the same filename, but different extensions. Signtool may be run multiple times on the same hierarchy of files, for producing updated signed JARs. Each time, it produces a signature block file named "zigbert.[rd]sa" and the related files are also named zigbert.<something>. (See the JAR specification for all the extensions of the related files.) This is intended to ensure that signtool replaces any old signature files each time it is run, rather than adding signature files to those from previous runs. When Signtool is run with the -Z and -X options, it puts the file named zigbert.[rd]sa first in the zip. If you choose to do the zip step yourself and you are creating an XPI file, you will want to put that file first. > Signtool will tell you if your file is a valid JAR file, but will not > check that it is also a valid XPI file. More accurately, signtool will verify the signature in the zigbert.[rd]sa signature block file, and will verify the file hashes in the related zigbert files. It will not verify that the zigbert signature block file is the first file in the JAR. So, if you have an XPI file whose first file in the zip archive is not zigbert.[rd]sa, signtool may tell you that it is a valid signed JAR file, but that will not actually mean that it is also a valid signed XPI file. If signtool says "this is not a valid signed JAR file", then it is also not a valid XPI file. But if signtool says "this is a valid signed JAR", it may or may not also be a valid XPI. > Ultimately, FireFox or SeaMonkey themselves are the best test tools for > XPI files. ... for the reasons given above. -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
