Author: Shawn Wilsher

So, as many people running nightlies may have found out, the version of the DOM Inspector that they got from AMO didn’t work. I resolved that in bug 420047 earlier today. That means that as of tomorrow’s nightly, DOMi should work again. That’s right – it wasn’t a problem with the xpi, rather we were a bit too aggressive in removing files (namely, inspector.xpt) when DOMi was disabled by default.

Any other issues found should be filed as new bugs. I’ve opened up a meta bug to track the release of 2.0.1 of the DOM Inspector.

I just resolved bug 271812, which means you can now get the DOM Inspector for 1.9 products off of AMO. Nightly testers (and future beta 4 users) will notice that it’s no longer included by default in the product. You can get the add-on here! The UI is no longer coupled to the release of Firefox, so we can update things independent of the Firefox release cycle. Certain back-end changes will still depend on the Gecko release schedule, but I think I’m OK with that since that would require shipping binary components if we didn’t want to do that. Binary components are hard, and other add-ons (like Firebug) depend on some of them too. It’s best if they stay a part of layout for the time being.

I recently fixed Bug 416173, which changes how database connections are opened for mozStorage. The important thing to know is that they don’t throw if the database is corrupted or couldn’t be opened for whatever reason. You have to check the connectionReady property that’s always been there to know if it’s safe to use or not. I’ve filed bugs for components that I knew used the storage service, but I’m betting there are consumers out there on 1.9 that I don’t know about. This post is me telling you to file bugs to get those consumers fixed! Please mark those bugs dependent on 416173 too!

You’ll note that this was fixed roughly two weeks ago. That’s a good demonstration on just how busy I’ve been and why I’ve been essentially non-existent on irc. I cannot wait for school to be over!

That’s right! Last night I landed the latest version of SQLite to trunk. While generally updating SQLite is not so new-worthy, this time it is. You see, SQLite 3.5.x brings about some really awesome changes that consumers can take advantage of. The most important one for Mozilla (as I see it so far) is the ability to have the shared cache accessible on multiple threads. That means we can use database connections on multiple threads now while using the same cache. We can also use them at the same time (before, you could use them on different threads, but they would not have the same shared cache, nor could you use them at the same time). To see all the neat changes that we can now use, please read the SQLite docs.

So, now you have to secure your self-hosted addon’s updates, but you don’t want to have to sign your update.rdf file nor your install.rdf file. I was in that boat, and I thought I’d share my solution with other addon developers out there to make your lives easier.

I recently switched over to Dreamhost as my hosting, and lucky for me they make using a third party SSL certificate quite easy. The great folks at StartCom offer free Class 1 certificates, which is all you need to secure your updates. StartCom certificates don’t work in IE, but they do work in Firefox, so they’ll work great for securing your addon updates. Please note that using SSL over HTTP does require that you get a unique IP address for your server, which usually costs more from most hosting companies, so it isn’t a completely free solution.

Let’s get started by applying for your Class 1 certificate here. Select “Class 1 Certificate”, and press Continue. On the next page, you’ll want to select “Server Certificate (With CSR generation)”, and press Continue. At this point, you’ll be asked to provide some personal details. These details won’t appear in the certificate.

Their certificate creation wizard will walk you through the next few steps. Here, you’ll create your private key, ssl.key, certificate signing request, ssl.csr, and your certificate (they might have to hand verify details, so the certificate might not be instant), ssl.crt.

Now you have everything that you need. With Dreamhost, these next few steps are dirt simple. First, you’ll have to decrypt your private key that was generated for you. This is where that password comes into play that you are supposed to remember! You’ll need to find some unixy box (you can ssh into your Dreamhost box) and run the following command (you’ll have to upload your private key to the remote machine as well):
openssl rsa -in ssl.key -out ssl.decrypt.key

Now you can safely fill out the fields on your domain/subdomain page. In the field titled “Certificate Signing Request”, copy and paste the contents of ssl.csr. In the field titled “Certificate”, copy and paste the contents of ssl.crt. Finally, in the field titled “Private Key”, copy and paste the contents of ssl.decrypt.key. Make sure you use the decrypted key, otherwise you’ll get an error about using a password protected private key. Now that you have filled these fields out, you’ll have a new field on the top of that page that you won’t see (someone at Dreamhost should fix this) that lets you select if you want https://www.* or https://*. Select whichever one you used for your certificate application, otherwise users will be presented with an error.

There’s one last step here and you can have HTTPS working on your server. You need to contact Dreamhost support to have them install the intermediate certificate from SmartCom, otherwise your users will get an invalid certificate error. So, download sub.class1.server.ca.crt and upload it to your home directory, then fill out a support request asking them to upload it. Their wiki page on SSL has more details on this. You should get an e-mail from them informing that everything is all setup. After that, you are ready to serve secure updates!