Year of the Code Monkey
Because Jonah Bishop Said So
I’m in the process of getting CoLT and Googlebar Lite ready for Firefox 3. This involves making sure that I provide secure updates for my extensions. I have three choices as to how to go about doing this, and I don’t know what to do. Your input would be appreciated. Here are my options, along with the pros and cons of each:
Option 1: Host on addons.mozilla.org
The first option involves moving my extensions to the official add-ons site.
Pros:
- Very Easy
- Free
- No Development Changes Required
Cons:
- Breaks Existing User Updates (?): Many people download my extensions from Born Geek. When the new versions become available, how will they update? The
updateURLfor each extension points to Born Geek (unless you happened to download my extensions from the official site, in which case noupdateURLis provided at all). I’m not sure how this transition will be handled. - Update Delay: All extension updates must be ‘approved’ before they can be posted at the official site. This involves an upload delay, which at times, has been as long as several days.
- Cannot Track Downloads: Hosting the files here at this site allow me to track downloads to some extent. I also provide my extensions at the official site, so I don’t get all the download data that I could, but I still get a decent picture of overall downloads by hosting at my website.
- External Site May Go Down: This is likely to happen with any website, but being dependent on another website for your hosted files seems to add unnecessary risk of inaccessible files.
Option 2: Add SSL to borngeek.com
Pros:
- No Development Changes Required
- Relatively Easy
Cons:
- Costs Money: In order to go this route, I need a signed certificate and a unique IP address, both of which cost money (roughly $70 a year, total).
- Requires Setup: All of the certificate stuff needs to be set up. This will take some time to figure out, though it’s a one-time cost.
Option 3: Digitally sign each extension
Pros:
- Free
Cons:
- Development Changes Required: My development process would have to significantly change in order to go this route. The McCoy signing tool cannot be driven from the command line (a bug has already been filed about this), so I cannot easily automate the packaging process. Some home-brew automation projects have popped up, but there’s no guarantee they will continue to be maintained over time.
- Not Entirely Straightforward: The signing process is currently very poorly documented. I’m not entirely sure what has to be signed and what doesn’t.
- Key Backup: Extension signing basically uses a public/private key pair for signing. Lose the private key, and it’s game over.
- McCoy Still ‘Beta’: The McCoy tool is still at version 0.5. Will future changes break my signed extensions? Are there bugs in the current version that will have some unforeseen consequence in the future?
So what do I do?
Does anyone have a suggestion for what I should do here? Comments? Questions? Any and all feedback would be greatly appreciated.
March 16, 2008 at 8:21 am
Seems to me that a lot of this is personal preference. Options 1 and 2 are easier, but 3 once implemented would give you the download data you want without spending money on SSL certs.
Personally, I’d be happy to just see everything go to the AMO site, since I tend to download everything from there anyway.
March 17, 2008 at 7:59 am
A few thoughts:
“The updateURL for each extension points to Born Geek.”
* Maybe you could use .htaccess to redirect the update URL to the Mozilla site? (Not sure if FF would follow the redirection though.)
* The updateURL is in install.rdf, but the updates.rdf file at that URL could just have its updateLink attribute point to the Mozilla site, right? For future versions, the packaged install.rdf could have an updateURL that points to the Mozilla site, so only users who haven’t updated will be hitting the borngeek update URL.
As for McCoy, yeah it’s really obnoxious. It can’t be run from a command line, and it messes up your updates.rdf file (and won’t use Windows line-breaks even when run on Windows). For my toolbars (which are internal for my company, so option 3 was the only one that could work for me), here’s my process (I actually had to create a note_to_self.txt so I could remember how to do this):
1. Update current version of app in install.rdf and updates.rdf.
2. Run package.bat (Ideally, this would go ahead and sign the app for me if McCoy could be run from command line.)
3. Copy updates.rdf and toolbar.xpi to webserver_backup dir.
4. Sign updates.rdf that is in webserver_backup dir:
a. Run McCoy.
b. Select “Sign”.
c. Choose the updates.rdf in webserver_backup dir.
5. Upload webserver_backup dir to webserver.
That way I’m only running McCoy on a copy of the updates.rdf file (I keep the original “clean”). You also have to get the updateKey for install.rdf, but you only have to do that once (you can just right-click on the key in McCoy and select “copy public key”, that way it doesn’t mess up your install.rdf). I’ve been able to install and update the toolbar on FF3b4 this way.
March 17, 2008 at 8:53 am
I typically get my extensions directly from the Mozilla add-ons site. I would think most people would get extensions this way. I would be most likely to get stuff from official sites rather than personal sites, unless I know the person. Which is odd, because I know you…
Maybe they will add stat support for developers of extensions soon. It would seem like a logical path to take for them, if more people will be moving in this direction.
The delay stinks too, but hopefully they would improve this as well, if more people are moving in this direction.
I feel the official site is the way to go. People are into one-stop-shops where they can get everything they need without going all over the place. Just my opinion.