[Project_owners] newbie question: how do secure updates for FF 3.0 work?

Godmar Back godmar at gmail.com
Sun Feb 17 06:15:29 PST 2008


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 <treitmayr at yahoo.com> 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 <godmar at gmail.com>
> An: Mozdev Project Owners List <project_owners at mozdev.org>
> 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
> <silfreed at silfreed.net> 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    <silfreed at silfreed.net>    Site Developer
> >  Mozdev.org          http://www.mozdev.org
> >
> > _______________________________________________
> >  Project_owners mailing list
> >  Project_owners at mozdev.org
> >  https://www.mozdev.org/mailman/listinfo/project_owners
> >
> >
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> https://www.mozdev.org/mailman/listinfo/project_owners
>
>
>  ________________________________
>  Lesen Sie Ihre E-Mails auf dem Handy..
> _______________________________________________
> Project_owners mailing list
> Project_owners at mozdev.org
> https://www.mozdev.org/mailman/listinfo/project_owners
>
>


More information about the Project_owners mailing list