657494 - add XPI code-signing tools to 'cfx xpi --sign'

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Brian Warner [:warner :bwarner]]

In lieu of the ECDSA-based signatures removed from 1.0 in bug 654588, it might be useful to teach cfx how to create signed XPIs using the traditional RSA-based format. First step is to research+document what exactly these signatures get you, and who pays attention to them, since without knowing that, it's kinda pointless. Second step is to adapt Wladimir Palant's code (http://adblockplus.org/blog/signing-firefox-extensions-with-python-and-m2crypto) into an option to 'cfx xpi', maybe 'cfx xpi --sign'. Third step is to talk with the Flightdeck folks to figure out how it should interact with that.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

We should at least figure out what signatures get us.  P2 for investigation and determination of what, if anything, we should do here.

Comment 2

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Has anything been figured out yet? The lack of activity in this bug seems to indicate "no".

Comment 3

[Brian Warner [:warner :bwarner]]

Not really. Here's my guess based upon hearsay and rumor:

 Traditional XPI signatures tie the addon contents to a given key. I believe
 that once an addon is installed, subsequent updates can be limited by data
 in the manifest.rdf, either to a specific HTTPS URL, or to a given key.

 The HTTPS path is more common: if you go that way, your reliance set
 includes the usual CA suspects and the server that hosts your XPI. If you go
 with the key, the reliance set is just you (i.e. the party that holds the
 privkey).

 I'm a big fan of end-to-end checks, so the pubkey approach appeals to me
 more. Part of the reason that few people use it is that the tools are
 painful to use. The other part is that developers might find it
 harder/annoyinger to hang on to a per-addon privkey (or at best a privkey
 that you only use for signing addons), than to hang on to their
 server-uploading SSH key/passphrase (which they also use for making other
 updates).

Do we have any authorities on signed addons around here who could confirm
this?

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

This will probably work better as a Feature Page for now.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(Pushing all open bugs to the --- milestone for the new triage system)

Comment 6

[Will Bamberg [:wbamberg]]

I don't think this is a docs bug.

Comment 7

[Steve Sobel]

Just chiming in here to say:

I would love to see this.  I self-host an addon and it is an absolutely painful process to deploy a new version.

For a chrome extension, I click "pack extension", point to the directory, point to my certificate and I'm done.

For a new FF addon, I must:

- cfx xpi (with params for update URL)

- extract RDF file from XPI

- sign RDF file using external software (McCoy)

- shove RDF file back into XPI

- get MD5 hash of XPI using external software (some addon I found for Windows, not Mozilla related at all)

- manually edit the other RDF file putting the md5 hash in

- sign that file

- verify signings were correct


Streamlining this process would be fantastic.

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

(In reply to Wes Kocher (:KWierso) from comment #4)
> This will probably work better as a Feature Page for now.

Here it is, just a few months later: https://wiki.mozilla.org/Simplify_or_automate_signing_of_Jetpack_XPIs

Comment 9

[Hector Zhao [:hectorz]]

Come across this one when searching for McCoy related bugs.

The original bug was talking about signing an extensions as describe in [1], but all later comments were talking about signing an update.rdf for self-hosted extensions as described in [2], which one is this bug really about?

[1]: https://developer.mozilla.org/en-US/docs/Signing_a_XPI
[2]: https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Signing_Update_Manifests

Comment 10

[Dave Townsend [:mossop]]

(In reply to Hector Zhao [:hectorz] from comment #9)
> Come across this one when searching for McCoy related bugs.
> 
> The original bug was talking about signing an extensions as describe in [1],
> but all later comments were talking about signing an update.rdf for
> self-hosted extensions as described in [2], which one is this bug really
> about?

It was certainly originally about signing the XPI itself, but most of the people commenting don't understand the difference.

Comment 11

[Erik Vold [:erikvold] (please needinfo? me)]

Can we wontfix this?

Comment 12

[Dave Townsend [:mossop]]

Probably yes however we'll need to watch https://groups.google.com/forum/#!topic/mozilla.addons.user-experience/1nHIIXNH7D0 closely and see if signing becomes more important through that.