Paul "suckerformimi" wrote:
I've seen this asked many times, but I haven't seen any solutions
posted.
What zip utility can I use under windows to create a signed XPI?
I can't find any that let me control the order of the files.
Don't look for a special zip tool. Look for a JAR signing tool, and
an ordinary zip tool. Any command line zip tool will let you control
the order in which the files are added to the zip archive. It might
require you to run the zip tool once for each file to be added.
If you get a signed XPI file whose contents are not in the right order,
you can merely unzip its contents into a tree of files, and then rezip
those files into a new zip file in the right order.
Any signed XPI file is actually a signed JAR file. The important thing
about both types of files is *NT* that they're zip files. There's
nothing special about the zip format itself in XPI files or JAR files.
This is somewhat explained in
The important thing is that the files that make up the contents of the
zip must conform to the specification of a signed JAR (Java ARchive).
To make either a signed XPI or signed JAR file takes two steps:
1. set the hierarchy of files according to the signed JAR specification,
using any of the spec-conformant JAR signing tools, then
2. zip them up.
In the case of XPI files, the files have to be zipped up in a certain
order. But that's a mere detail of how they're zipped up, after the
full signed JAR contents have been created. Creating the files that
go into the JAR (zip) is the hard part.
I am aware of two tools for creating signed JARs.
1. Sun's "jar" and "jarsigner" tools (which make a JAR, and then sign it)
2. NSS's "signtool"
The JAR specification does not impose any order on the files within the
zipped JAR. The files may appear in any order in the zipped JAR.
It permits multiple signatures ("signature block" files) to exist in the
JAR, with different subsets of files signed with each signature block.
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.
NSS's signtool utility has some command line options that will also zip up
the results. The -Z option does this. When used together, the -Z and -X
options cause the "zigbert.[rd]sa" file to come first in the zipped output.
Whether -Z is used or not, signtool leaves the hierarchy of files intact
so that any ordinary zip tool may be used to do the final zip step. This
gives the zip creator maximum flexibility over the type of compression
used with each file, among other things.
Also, what's the easiest way to tell whether my XPI is properly signed?
Is there an NSS utility that does this?
Signtool will tell you if your file is a valid JAR file, but will not
check that it is also a valid XPI file. Ultimately, FireFox or SeaMonkey
themselves are the best test tools for XPI files.
Thanks in advance,
Paul

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.

Jan Steffen wrote:
I'm not too deep into this CA stuff, but there is http://www.cacert.org/
for example, which offers certificates for free.

CAcert.org's root certificate isn't (yet) included in Firefox by
default, so CAcert.org couldn't serve for this purpose. Given the
current status of their CA application, Firefox 3 is the earliest
Firefox release in which CAcert.org could hope to be included.

However note if there's a consensus that we should move to signing
extensions, especially those distributed under Mozilla auspices, and
money is the only remaining issue in getting extensions signed, then I
think there are ways to resolve that issue. This includes the
possibility of having the Mozilla Foundation partially subsidize the
purchase of code signing certs for volunteer contributors. (There are
other possibilities as well; for example, we could also consider
negotiating a group purchase of code signing certificates.)

Frank

Paul "suckerformimi" wrote:
It took us an immense amount of effort and a couple of favors before we
managed to sign our code. Some bugs in the NSS tools meant NSS couldn't
understand our pvk and spc files. We only got to the end because
Firefox support was a huge priority for us.

I wouldn't say NSS has any bugs with respect to .pvk files or .spc files.
NSS simply doesn't support the old proprietary pvk file format, & never has.

Microsoft barely supports it any more, also. The Windows 2000 and Windows XP
certificate export wizards do not support the .pvk files. (So says

In order to be able to "import" pvk files into the windows cert and key
store on a WinXP or Win2003 system, one must download a special "pvkimprt"
program from a MS web site. For more info, see

pvk files use an old proprietary format (that various parties claim belongs
to Microsoft, Verisign, and/or Thawte.) It was superseded by PKCS#12
file format (a.k.a. .p12 or .pfx files) about 10 years ago (!).
Microsoft and Netscape and RSA Security (and others) worked together to
come up with an open standard that they could all use, and .p12/.pfx files
have been supported by Windows and Netscape (and now Mozilla) products
ever since. Jim Spring (recently seen in this newsgroup) implemented it
for Netscape back in 1996 or 1997, IIRC.

So the real mystery is why, in the year 2006, some software that does
"certificate enrollment" for code signing certs is still using the
obsolete and proprietary .pvk file format.

I'd really like to know what software was used to obtain the pvk file
that Paul "suckerformimi" obtained. (Paul wrote me that these files
were obtained by someone else at his company, and given to him, so he
does not know what software was used to obtain them.) IM, that
software should be replaced with software that uses .p12 files, ASAP.