Gervase Markham wrote: > Benjamin Smedberg wrote: >> We already support hashes specified by the upate.rdf for the XPI, and AMO >> uses this to serve the XPIs over http. However, the issue at hand is when >> the extension has nothing to do with AMO, and serves the update.rdf over >> HTTP or the XPI over HTTP without specifying a hash. > > Well, the latter we can just forbid - i.e. refuse to download the > update. There's no reason not to put the hash in the XPI. It doesn't > cost anything to get hash-generating tools :-)
Agreed and my plan is to forbid updates without hashes, this just leaves the issue of getting the update.rdf in a secure fashion. > Let's look at scenarios here. Someone wants to make their extension > available. They can either: > > - Host it on a.m.o, for free, taking advantage of the security > infrastructure and download bandwidth > > - Host it themselves, and pay $40-$60 per year for a fixed IP and > free/cheap SSL certificate, and some bandwidth to serve up the copies. > > Who are we not serving here? If people don't want to pay any money to > put out an addon, a.m.o. is there for them. Why are we trying to solve > this problem? Let's just make updates.rdf over HTTPS compulsory. Yes that plan allows everyone to host, however we are forcing them down a path they previously didn't want, i.e. hosting on AMO, or paying for the privilege of writing extensions. Don't get me wrong, I would almost love it if this was the chosen route, it's a piece of cake to implement. The question is do we want to make the implementation easy for us at the expense of making things harder than they need to be for the extensions community? Dave _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
