1 |
On Monday 13 January 2003 05:24 am, Paul de Vrieze wrote: |
2 |
> Maybe the easiest way would be that some/all rsync mirrors would offer |
3 |
> rsync over ssl, so that the origin servers could be authenticated. This |
4 |
> would also mean some changes for clients to be able to use it. |
5 |
|
6 |
I think something does have to be done about this. |
7 |
|
8 |
There was a discussion about this (which I took part in) on gentoo-user and |
9 |
then the gentoo forums. For those who are interested: |
10 |
|
11 |
http://forums.gentoo.org/viewtopic.php?t=26137 |
12 |
|
13 |
Personally, I think it's better to cryptographically sign the portage tree |
14 |
somehow at the source, then distribute it in the current manner. This method |
15 |
has the advantage that we need not implicitly trust the rsync mirror admins |
16 |
(as we currently do) and that the tree is immune to man-in-the-middle attacks |
17 |
as it is transfered between official site and mirror or between mirror and |
18 |
client. Secure rsync (via SSL or whatever) doesn't completely solve the |
19 |
problem. |
20 |
|
21 |
That said, there's many ways of signing the portage tree. I advocate having |
22 |
the master rsync server automatically sign the tree as it checks out the CVS |
23 |
tree. There's been a lot of talk at various times about developers signing |
24 |
ebuilds individually, but I'm not sure that actually gains us anything. I |
25 |
also advocate building a time-dependence into the signatures. Read my forum |
26 |
posts for my complete musings on the matter, but here's a summary of my |
27 |
points: |
28 |
|
29 |
1) An authentic but out-of-date tree can be just as dangerous as a inauthentic |
30 |
tree. |
31 |
2) CVS works against per-developer signing of ebuilds. Consider "$Version: $", |
32 |
etc. |
33 |
3) Ultimately we are forced to trust CVS, so we can't realize any additional |
34 |
security from per-developer signatures. |
35 |
|
36 |
I present a method for efficiently signing the portage tree at the source |
37 |
while avoiding, to some extent, the race-condition type pitfalls of rsyncing |
38 |
while changes are in progress, etc. Read my forum posts for details. |
39 |
|
40 |
I don't pretend to know everything about this sort of thing, so comments are |
41 |
very welcome. |
42 |
|
43 |
Evan Powers |
44 |
|
45 |
-- |
46 |
gentoo-dev@g.o mailing list |