How to Digitally Signing Firefox Extensions
James M
I'm hoping someone can shed some light regarding some confusion on
digitally signing XPI files so that they are compatible with Firefox
3.
http://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility
The above resource states that the install.rdf file must have an
em:updateHash key that is generated against the XPI. I'm afraid that
is where I become lost. How do you generate a key against an XPI file
that you haven't assembled yet?
From what I can tell this is the chicken and the egg problem: How do
you include the key generated against the XPI and include it in the
install.rdf file when the install.rdf file is packaged inside the XPI.
Can someone please explain how this process works?
Also, there is an em:signature entry in the install.rdf as well. How
do I create this? Also, what goes in the update.rdf file on my
server? Is this the same key from the XPI?
Thanks in advance for explaining how to get the chicken without first
having an egg.
James
John J. Barton
> Hello,
>
> I'm hoping someone can shed some light regarding some confusion on
> digitally signing XPI files so that they are compatible with Firefox
> 3.
>
> http://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility
>
> The above resource states that the install.rdf file must have an
> em:updateHash key that is generated against the XPI. I'm afraid that
> is where I become lost. How do you generate a key against an XPI file
> that you haven't assembled yet?
James, its the update.rdf that gets the updateHash value.
>
> From what I can tell this is the chicken and the egg problem: How do
> you include the key generated against the XPI and include it in the
> install.rdf file when the install.rdf file is packaged inside the XPI.
The install.rdf has the public key and the update URL.
>
> Can someone please explain how this process works?
This time:
Put the public key and update URL into your install.rdf,
zip your extensions,
ship it.
Next time:
Do the same steps with your new version, put it at the update URL.
Compute its updateHash, put that in to your update.rdf
Sign the update.rdf
Put the update.rdf at the update URL.
When users update, FF3 does:
get update.rdf
use public key in user's copy of install.rdf to verify the update.rdf
if good download the extension,
compute its hash,
compare to the one in the verified update.rdf.
>
> Also, there is an em:signature entry in the install.rdf as well. How
> do I create this?
mccoy.exe
Also, what goes in the update.rdf file on my
> server? Is this the same key from the XPI?
The update.rdf gets the updateHash from the *new* version and is signed
with the same key as you sent in the old install.rdf.
>
> Thanks in advance for explaining how to get the chicken without first
> having an egg.
More like turkeys and chickens at first. Once you get it working you're
thinking this is pretty need, all client side security mechanism.
> James
Mook
> Hello,
>
> I'm hoping someone can shed some light regarding some confusion on
> digitally signing XPI files so that they are compatible with Firefox
> 3.
>
> http://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility
>
> The above resource states that the install.rdf file must have an
> em:updateHash key that is generated against the XPI. I'm afraid that
> is where I become lost. How do you generate a key against an XPI file
> that you haven't assembled yet?
periodically fetched to check for new updates. It lives on some HTTP
server. It is <em:updateKey> that goes into install.rdf.
<em:updateKey> (install.rdf) + <em:updateHash> (update.rdf) ->
<em:signature> (update.rdf)
See also the first example update.rdf file in
http://developer.mozilla.org/en/docs/Extension_Versioning,_Update_and_Compatibility#Update_RDF_Format
--
Mook