Thank you, I'll check this out. For the benefit of the rest of the list (and anxious extension authors frantically googling for information that is splattered across numerous bugzilla entries and mozillazine forum threads), let me summarize what I've learned from a personal email exchange with David Townsend (Mossop), who is in charge of the secure extension update implementation.
It turns out that - fortunately - things aren't nearly as dire as they seemed. FF3.0 will disable incompatible extensions only if it can't find a compatible extension update at (browser) update time. A compatible extension is one that's either signed or has a secure update URL. It is not necessary to already be signed or have a secure update URL in the extensions your users have already downloaded for Firefox to install this new, compatible extension. Instead, the existing, nonsecure update path is used. However, the downloaded extension will not be activated unless it itself contains a secure update path. To sum up, all we need to do is have a compatible version on our servers on the day Firefox publishes the FF 3.0 update. Regarding the signing process. McCoy, it turns out, is a GUI-based tool designed for signing individual extensions. It's not suitable for batch mode. There may be a version that can be run from the cmdline in the future, but it's not clear when. In addition, little development effort is directed at McCoy on Linux, leading to it being unstable or not running at all on some distributions. This statement is true as of February 2008. - Godmar On Feb 17, 2008 7:21 AM, Thomas Reitmayr <[EMAIL PROTECTED]> wrote: > > Hi Godmar, > there is another tool called Spock which allows for automated updates. You > provide your regular update.rdf on the command line and it will sign it and > write the result to stdout. Check out my original update.rdf (called > checkyesss.xml at > http://www.mozdev.org/source/browse/checkyesss/src/checkyesss.xml?rev=1.70;content-type=text%2Fx-cvsweb-markup) > and the invocation of Spock in the Makefile > (http://www.mozdev.org/source/browse/checkyesss/src/Makefile?rev=1.24, > search for SIGN.CMD). > You will loose your comments in update.rdf but at least a header can be > re-added without problems. > Hope that's helpful for you. > -Thomas > > PS: Spock can be found at http://hyperstruct.net/projects/spock. I had to > apply a small patch (see my comment there) and added the sources to my > respository at > http://www.mozdev.org/source/browse/checkyesss/3rd-party/spock/. > > > ----- Ursprüngliche Mail ---- > Von: Godmar Back <[EMAIL PROTECTED]> > An: Mozdev Project Owners List <[email protected]> > Gesendet: Freitag, den 15. Februar 2008, 23:04:47 Uhr > Betreff: Re: [Project_owners] newbie question: how do secure updates for FF > 3.0 work? > > > On Fri, Feb 15, 2008 at 3:49 PM, Douglas E. Warner > <[EMAIL PROTECTED]> wrote: > > > > If you'd like to see any of our roadmap priorities changed or rearranged, > let > > us know. > > > > Well, I would very much like a way to provide automatic updates to my > users. If I understand Andrew's reply correctly, the only way to do > that is to force an update (and switch to updateKey-signed) xpis while > they are still using 2.0. (*) This would be a huge hassle for us, > because don't actually create .xpi files - we provide a web-based > system (libx.org/editionbuilder) that does. Doing what you suggest > would force us to either abandon this system by which a community of > adopters creates .xpi files (and tests them, etc.), or coerce all of > them to rebuild and retest their .xpi files. > > The other options you mentioned (hosting on .mozdev.org, or on > addons.mozilla.org) obviously don't work in our setup, either. > > I find it hard to believe that there's no way to grandfather existing > projects into the new 3.0 framework - I'm not asking for you to > tolerate unsigned xpis, but at least a migration path should have been > provided. Is there really no migration path? (Note that we control > the updateLink location. We could, conceivably, redirect those to a > https URL. Would that help us?) > > - Godmar > > (*) Although you said: > "Right now the best thing you can do is being using McCoy [1] to sign your > update manifests and add the updateHash to your files. This will allow you > to serve your update.rdf files from http sites securely and provide > automatic > updates." - are you implying that following this path would provide a > means to participate in automatic updates even without forcing a > pre-3.0 update? > > does that mean that doing so will allow an update path when 3.0 comes > around? > > > -Doug > > > > [1] http://wiki.mozilla.org/McCoy > > [2] http://bugzilla.mozdev.org/show_bug.cgi?id=17302 > > [3] https://www.mozdev.org/bugs/show_bug.cgi?id=18526 > > > > -- > > Douglas E. Warner <[EMAIL PROTECTED]> Site Developer > > Mozdev.org http://www.mozdev.org > > > > _______________________________________________ > > Project_owners mailing list > > [email protected] > > https://www.mozdev.org/mailman/listinfo/project_owners > > > > > _______________________________________________ > Project_owners mailing list > [email protected] > https://www.mozdev.org/mailman/listinfo/project_owners > > > ________________________________ > Lesen Sie Ihre E-Mails auf dem Handy.. > _______________________________________________ > Project_owners mailing list > [email protected] > https://www.mozdev.org/mailman/listinfo/project_owners > > _______________________________________________ Project_owners mailing list [email protected] https://www.mozdev.org/mailman/listinfo/project_owners
