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.
We should at least figure out what signatures get us. P2 for investigation and determination of what, if anything, we should do here.
Priority: -- → P2
Has anything been figured out yet? The lack of activity in this bug seems to indicate "no".
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?
This will probably work better as a Feature Page for now.
(Pushing all open bugs to the --- milestone for the new triage system)
Target Milestone: Future → ---
I don't think this is a docs bug.
Component: Documentation → General
QA Contact: documentation → general
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.
(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
Come across this one when searching for McCoy related bugs. The original bug was talking about signing an extensions as describe in , but all later comments were talking about signing an update.rdf for self-hosted extensions as described in , which one is this bug really about? : https://developer.mozilla.org/en-US/docs/Signing_a_XPI : https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility#Signing_Update_Manifests
(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 , > but all later comments were talking about signing an update.rdf for > self-hosted extensions as described in , 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.
Can we wontfix this?
Priority: P2 → --
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.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.