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

Thomas Reitmayr treitmayr at yahoo.com
Sun Feb 17 04:21:13 PST 2008


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






      Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mozdev.org/pipermail/project_owners/attachments/20080217/eb8969e9/attachment.html 


More information about the Project_owners mailing list