How do you sign an extension?

[sboulema]

hmm weird it appears as signed to me...

[Robert S.]

I found a test page where I was able to see an extension signed in the Suite and it showed as not signed in Firefox... very strange. The test page had signed the xpi using the new version of the signtool as well. Not sure what is up but it appears to be rather flakey at present.

[eviljeff]

This (from Maxx link) appears as unsigned in Firefox's installation window.

Not with me.

[Lost User 23429]

Would it be possible to use GPG to sign an extension? GPG signing would probably be so much easier.

[Robert S.]

Would it be possible to use GPG to sign an extension? GPG signing would probably be so much easier.

You can sign it with GPG but the extension manager only shows extensions signed with a code signing cert as signed.

[alanjstr]

Making sticky until someone adds this to the WIKIs

[Lost User 23429]

I just don't see the value of using signing as a security measure but I am open to it... I just don't see any scenarios that are reasonable where having extensions signed would provide more benefit than the issue with people misinterpreting what signing actually means.

Assuming that tempering with a signed extension nullifies the signature(is md5sum a candidate here somehow?), I would consider installing a signed extension safer than a non-signed one. This would atleast confirm that they are safe to use provided they are from a trusted source in the first place. As you can't really make a user to not submit private information on a non-secure channel, we can't *make* users to install only signed extensions. It is the responsibilty of MoFo and the user/tester community to educate the users so that they know how to check the validity of the certificate and take necessary actions depending on the outcome.

[Lost User 23429]

Making sticky until someone adds this to the WIKIs

What is needed at this point is a How to on signing an extention with test cases so that only the vanilla version of the extension comes up as signed. None of the versions of the extensions which have been tempered with or are distributed by url other than the trusted one (something similar to target application id??) should come up as signed.

[Robert S.]

Assuming that tempering with a signed extension nullifies the signature(is md5sum a candidate here somehow?), I would consider installing a signed extension safer than a non-signed one. This would atleast confirm that they are safe to use provided they are from a trusted source in the first place. As you can't really make a user to not submit private information on a non-secure channel, we can't *make* users to install only signed extensions. It is the responsibilty of MoFo and the user/tester community to educate the users so that they know how to check the validity of the certificate and take necessary actions depending on the outcome.

If you are installing from a specific extension site the concern is if the site had been compromised... this is of course assuming most people install from a specific site like U.M.O. or the T.E.M. which I believe the vast majority of extensions are installed from. If the site had been compromised and extensions have been replaced with extensions that contain malware there is little to prevent these extensions from being signed as well though the likelihood of them being signed is quite small. The point is that the likelihood of this occurring with either of these sites is also quite small. Has this even happened without signing?

As for them being safe to use... this only gaurantees they haven't been changed from the time of the initial packaging as long as it wasn't also signed when repackaged. I also believe based on several posts that there are quite a few average users that believe that if an extension is signed it is safe to use in that it won't have conflicts with existing extensions, will work without problems, etc. instead of that it hasn't been modified since it was packaged.

What is needed at this point is a How to on signing an extention with test cases so that only the vanilla version of the extension comes up as signed. None of the versions of the extensions which have been tempered with or are distributed by url other than the trusted one (something similar to target application id??) should come up as signed.

I found enough details on how to sign an extension via a google search and reading bugs to sign an extension with a test cert though I had to compile the tools to do so due to a bug in the current release of the tools. Even with the process documented a code signing cert will be needed to distribute the extension and the cost of doing this for an extension that is free is to say the least prohibitive... not to mention the questionable value of signing and misinterpretation of what signing means in many cases.

I can see value in signing within a corporate environment if it is possible to prevent the installation of extensions that aren't signed (especially if installation can be limited to specific certs) along with the corporation providing approved extensions that are signed. I just haven't seen a real life example in relation to extensions where signing has or could have provided value besides a warm fuzzy for some users based upon misinterpretation of what signing means. There is of course the possibility that a site has been compromised and the extension packages replaced but I do wonder how many users would just install the unsigned extensions even in this instance.

[iosart]

A few links on signing extensions:

http://www.j-maxx.net/tutorials/xpi_code_signing/
http://www.mozilla.org/projects/securit ... tutil.html
http://docs.sun.com/source/816-5531-10/app_sign.htm
http://certs.mozdev.org/

https://bugzilla.mozilla.org/show_bug.cgi?id=273406

Also, from netscape.public.mozilla.crypto:

NSS's signtool was originally developed to sign "JAR" files. JAR files are
ZIP files whose contents are organized according to the JAR specification.
mozilla's XPI files are similar to JAR files, and for years one could sign
XPI files with ordinary JAR signing tools, such as signtool.

But about a year ago mozilla was changed to require the files in the XPI to
be in a slightly different order than in the normal order for JAR files.
Consequently, the normal JAR file signing programs create signed XPI files
that are not in the order that mozilla now desires.

Several months ago, someone contributed an enhancement to signtool so that
it can produce signed files that conform to the JAR specification, or that
conform to the XPI specification. That new version of signtool, known as
version 3.10, was (and is) intended to be released with NSS 3.10.

But NSS 3.10 has been delayed. It has been a year since 3.9 was released
and 3.10 has not yet been released. Consequently there are presently no
officially built, QAed and released binaries of signtool 3.10. People who
want signtool 3.10 presently must build it themselves, or get someone to
build it for them.

I have been told that it is possible to create an ordinary signed JAR file
using any of the older signtool versions, then unzip the contents onto a
local disk with an ordinary zip tool, and re-zip them into a new zip file
with the files in the order desired by mozilla. But I have never tried it.

In a typical signed JAR file, the first 3 files are (in order)

META-INF/manifest.mf
META-INF/zigbert.sf
META-INF/zigbert.rsa

(names of the .sf and .rsa files may be other than "zigbert").
Order of the files in the jar is not supposed to matter.

A mozilla XPI file is a signed JAR file with one additional requirement:
the first file MUST be the .rsa file.

The order produced by signtool 3.10 with the -X option is:

META-INF/zigbert.rsa
META-INF/manifest.mf
META-INF/zigbert.sf

Finally one caveat: there are bug reports stating that FF 1.0 fails
to validate properly signed XPI files. E.g.
https://bugzilla.mozilla.org/show_bug.cgi?id=273406
If this report is true, we may have to wait for FF 1.1 for signed
XPIs to work right. <sigh>

I guess a good tutorial/howto is still needed on this.

[jensb]

I found enough details on how to sign an extension via a google search and reading bugs to sign an extension with a test cert though I had to compile the tools to do so due to a bug in the current release of the tools.

The other issues aside - could you perhaps put up the compiled binary, so others can use it out-of-the-box? (a Windows build would be best, of course...)

[Robert S.]

Not a problem... I'll check which dll's are needed and put up a link to them and the exe tomorrow. If I have the time I'll add some info on how to use a test cert as well.

[iosart]

The other issues aside - could you perhaps put up the compiled binary, so others can use it out-of-the-box? (a Windows build would be best, of course...)

This link (which I posted above) has a patched Windows binary:
http://www.j-maxx.net/tutorials/xpi_code_signing/

[Robert S.]

Thanks iosart...

[iosart]

If I have the time I'll add some info on how to use a test cert as well.

A short HOWTO on signing with a test certificate (and maybe also a real one) would be great
It seems like the info at the links I posted above is somewhat outdated/incorrect (although still useful)