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
Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s
mit dem neuen Yahoo! Mail. www.yahoo.de/mail_______________________________________________
Project_owners mailing list
[email protected]
https://www.mozdev.org/mailman/listinfo/project_owners
