Talk about add-ons and extension development.
Hi all, we are currently investigating ways to improve the security of the automatic add-on update mechanism. There are a couple of proposals knocking about and I would like to get some feedback from you if you host your own add-ons and updates (on your own website, not on addons.mozilla.org).
First can you say why you don't host on AMO (doesn't need to be long winded, just want to get an idea of the main issues here).
On the website you host at, do you already use https to deliver the update.rdf and/or the xpi's.
If not what would you think of a plan to only allow automatic updates to extensions that host their update.rdf on a https server (certificates appear to cost from $20 per year), would you be happy to pay that extra money, or move to AMO?
Finally if you still want/need insecure delivery of update files, what would you think of adding an extra step of adding a digital signature to your update.rdf (hopefully just a few commands but still added work nontheless).
There is a bug open on this however I'd ask that you keep your replies here, or to me directly if you prefer then I can collate some overview.
Last edited by Mossop on July 1st, 2007, 4:46 pm, edited 2 times in total.
Someone I've written an extension for hosts the extension on their site because it's sitting in the sandbox on AMO, where people have to log in and read scary warnings to get at it. He has an update.rdf that's not server over https because his site doesn't have https at all.
Because I don't want to lose the fun in coding.
I simply don't want to complicate my life with "submit-sandbox-review-comment-and-update-terror".
The question goes into the same direction as everything related to Mozilla/Firefox within the last months:
"Do you want to be pseudo-professional?"
Why not? As long as the steps are understandable...
Mainly because I prefer to schedule my releases myself (so I can react quickly in case of bustage).
Unfortunately that's no available option for my main server and not really implemented at mozdev.org, either.
I'd be happy if AMO allowed to just upload a custom update.rdf "no questions asked". Paying for something I offer for free doesn't really sound attractive...
How would that prevent MITM attacks? As long as the signature isn't bound to a (paid for) certificate, anybody could claim to be me, couldn't they?
No this can actually work. Similar to xpi signing you create a public key and private key. The public key gets distributed in your xpi and you sign the update.rdf with your private key. Then the app can verify the authenticity of the update file against the public key in the add-on.
There's a short discussion on the proposal for how to implement that ongoing on mozilla.dev.tech.crypto.
Thanks for the answers so far guys, keep them coming.
I do, but I do not want to jump through all the hoops to get my extension public. I think there needs to be some middle ground between public and sandbox. It is especially frustrating when there are a stack of public extensions that have obviously not been updated in ages (do not work on latest software versions).
So I will put the latest versions there but not as my main host.
Perhaps there needs to be a certified category of extensions, this would be a fairly small set that meet very strict criteria not just in quality coding but also need to be things that people actually want (match feature requests, or are downloaded a lot for example). These would be aimed at the average user who just wants things to work. Once an extension makes it to this list it should stay there unless it becomes obsolete, this way people will always know where to find it.
The current public could become easier to get your extension onto, if the developer feels it is ready for public consumption then it goes here. Obviously there needs to be some checks to make sure that the extension is not malicious or dangerous and is described correctly. Extensions in this list should be dumped to the sandbox if they do not work with the current software release or there should be an option to show extensions for previous software releases.
I would not want to pay that myself to give something away. I make donations to charity that help people in real need, $20 to provide my extension or $20 to give people food - easy choice.
If there are clear instructions and it is straight forward, yes.
Provided it does not impact on the development process, there is a way to install an extension without one if you really want to.
I don't know if this is within the scope of what you're look for, but regarding the sandbox a bit more... It would be good if extensions in the sandbox could be viewable and installable without requiring a log in. They could still be excluded from the non-sandbox search and listings. I think this would prompt the guy I wrote the extension for to solely use AMO. Currently, getting his site into his user's whitelists is easier than getting them to create an account on AMO.
I host my extensions at AMO but I think I'm gonna start doing it myself since I don't think this sandbox stuff is working very well. I made 3 extensions before the sandbox stuff started and they all got quite a few downloads and some comments and reviews. I´ve made 3 or 4 more that went in the sandbox, mostly after requests from this place and they have like 3 downloads each, usually the guy that requested them and maybe one or two others. Not that they're real big or important extensions but 3 downloads each? I'm guessing it's because Google doesn't index the sandbox pages so people have no way to stumble upon them. So yeah I´m gonna start hosting them myself and I would definitely not pay extra for https to give something away.
If you keep making the barrier to entry higher (sandbox, https) you'll get more and more people who'll just think "I'ts not worth the hassle" to publish their extensions.
Many thanks to everyone that replied to my questions about add-on updates. I have now put together the beginnings of a proposal for how we will deal with this. It is viewable here: http://wiki.mozilla.org/User:Mossop:Fx- ... teSecurity
I'm sure there will be some points in there that some of you will want to discuss, I think that here is a better place for discussion rather than on the wiki. If you do feel the need to put small comments on the wiki then please do so on the discussion page for the article, don't edit the main page directly.
It does not look like you have taken anything that anyone has said here into consideration. Maybe you could go back through some of the posts and tie in what people have said to specific parts of your proposal, so at least people feel they have been listened to.
Feel free to improve security, but you need to let people get their extensions out there.
I also did not notice how the proposed changes would impact on the development process, I assume that I will still be able to make my own extensions, for my own use without having to do anything that is in the proposal?
Are we doing this because of the wannabe security "expert" who "found" a hole and made people's extensions look bad without first contacting them and telling them of the exploit so they could have made changes before he made the notice public?
I am not happy with that guy at all. Personally, I think he is just trying to make his name known.
Is there anything in particular you are concerned about? The biggest issue raised both here and on the newsgroups was that requiring SSL was costly and difficult for authors. So we have decided to go the extra step and not require SSL for updates. The idea of allowing authors to upload their own update.rdf to AMO is unfortunately not really workable[/quote]
So long as you don't specify and updateURL in the extension's install.rdf then it will install since Firefox will presume you are using AMO for updates which is a secure URL. So during testing you need take no extra steps to make this work, it is only when yu come to want to release your extension and have it update from your own site that you would have to take any extra steps.
A public disclosure of the vulnerability has sped up activity on this yes, but it's not solely from that. However regardless of who found the hole, users are potentially at risk.
Mossop has fragmented this discussion into numerous sources: this forum, two or three newsgroup threads, bugzilla, his wiki, and possibly other sources of which I'm not aware.
In case anyone wants to see complaints/concerns at the other sources, here they are.
http://groups.google.com/group/mozilla. ... 1888d8708c
http://wiki.mozilla.org/User:Mossop:Fx- ... teSecurity
There's also at least one discussion in the dev.crypto newsgroup.
Last edited by ericjung on July 3rd, 2007, 12:00 pm, edited 1 time in total.
Or, you know, maybe he's just trying to get the word out to as many people as possible? Not everyone reads the forums, and not everyone reads the newsgroups.
And the wiki page, well the text right across the top (and the url - it's his talk page) seems to indicate that it is more or less used to keep track of the the information for himself...
Who is online
Users browsing this forum: No registered users and 0 guests