| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
| 6 |
|
| 7 |
|
| 8 |
|
| 9 |
Why not just take out those points in between? |
| 10 |
|
| 11 |
GENTOO_MIRRORS="http://gentoo.osuosl.org" emerge-webrsync |
| 12 |
|
| 13 |
|
| 14 |
|
| 15 |
Huh? How does this protect me from a potential MITM attack at my ISP, |
| 16 |
or on my neighbor's insecure wireless network, which my laptop is |
| 17 |
currently attached to? A simple traceroute shows sixteen hops between |
| 18 |
me and gentoo.osuosl.org. That's sixteen potential opportunities for |
| 19 |
nastiness.
|
| 20 |
|
| 21 |
How can I even be sure that I am connecting to gentoo.osuosl.org, when |
| 22 |
rsync is completely anonymous, with no ssl, no certificate chain, |
| 23 |
nothing to verify the server's identity other than its rsync banner???
|
| 24 |
|
| 25 |
I might care less about about verifying the integrity of my portage |
| 26 |
tree, if I could at least be more certain of what server I'm connecting |
| 27 |
to! Having neither assurance is a bit unsettling on a production |
| 28 |
machine.
|
| 29 |
|
| 30 |
The portage |
| 31 |
team would need to implement support for verifying the signature is valid. |
| 32 |
|
| 33 |
No, they /need/ not, and should not. I would be _thrilled_ to just get |
| 34 |
a signature with my tree, that I can manually verify by firing up gpg. |
| 35 |
No portage support is necessary for this interim solution. We all know |
| 36 |
something better is in the works for portage.
|
| 37 |
|
| 38 |
Work on portage should absolutely focus on the better, long-term, |
| 39 |
previously agreed-upon solution.
|
| 40 |
|
| 41 |
If the devs can just sign the tree, I can verify that my portage is |
| 42 |
what the devs intended me to have, and the devs can continue working on |
| 43 |
the more polished approach. Work on the best solution moves forward, |
| 44 |
while those of us with heightened security needs (today!) can be more |
| 45 |
confident of the integrity of our portage trees.
|
| 46 |
|
| 47 |
The infrastructure team would have to do some careful planning and possibly |
| 48 |
restructing of job control on the master rsync and cvs servers. |
| 49 |
|
| 50 |
While there is surely some work in the area of job control, it has been |
| 51 |
pointed out already that the proposed solution is not terribly resource |
| 52 |
intensive. So unless gentoo's infrastructure is already severely |
| 53 |
stretched to the max (is it? how do i know?), I can't see how this is |
| 54 |
a huge obstacle. Is there an admin who can weigh in with an informed |
| 55 |
answer on this? Too much speculation on this point, not enough fact.
|
| 56 |
|
| 57 |
Following this would be plan of action for the case |
| 58 |
that the all-powerful key is compromised. |
| 59 |
|
| 60 |
Key management/security/policy is an issue that will need to be |
| 61 |
addressed regardless of the mechanics of any signing process, so I |
| 62 |
don't see how that is a blocker to this proposal. The idea of a master |
| 63 |
key is equally applicable (and optional) to both the proposal on this |
| 64 |
list, and the one currently under development.
|
| 65 |
|
| 66 |
|
| 67 |
Then there is also the up to six |
| 68 |
month transition period between this solution and the solution that is |
| 69 |
currently being implemented. |
| 70 |
|
| 71 |
If portage support for this temporary hack is not implemented, there is |
| 72 |
clearly no six month transition period. Just that one day, those of us |
| 73 |
who have been manually verifying the signature will no longer need to |
| 74 |
do so.
|
| 75 |
|
| 76 |
|
| 77 |
I must be misunderstanding something, because I still fail to see what |
| 78 |
is so terribly difficult or impractical about merely generating a |
| 79 |
signature file. Hell, this could already be done and implemented in |
| 80 |
the time we've all wasted on this stupid thread.
|
| 81 |
|
| 82 |
No one is trying to derail or criticize or block the current |
| 83 |
implementation. We just want some basic assurances (now, today) that |
| 84 |
the scripts we're downloading are legitimately from the gentoo devs, |
| 85 |
who we trust. As it stands, we can verify neither the identity of the |
| 86 |
rsync server, nor the integrity of the portage tree we're downloading. |
| 87 |
That is indeed a problem. And it's one we can mitigate now, even if |
| 88 |
the best solution is still a ways off.
|
| 89 |
|
| 90 |
|
| 91 |
Cheers,
|
| 92 |
|
| 93 |
|
| 94 |
-C-
|
| 95 |
|
| 96 |
|
| 97 |
|
| 98 |
|
| 99 |
Jason Stubbs wrote: |
| 100 |
|
| 101 |
On Wednesday 10 November 2004 13:53, Chris Haumesser wrote: |
| 102 |
|
| 103 |
|
| 104 |
I trust the devs implicitly, but I do not trust, nor can I control, most |
| 105 |
of the points between them and me. |
| 106 |
|
| 107 |
|
| 108 |
|
| 109 |
Why not just take out those points in between? |
| 110 |
|
| 111 |
GENTOO_MIRRORS="http://gentoo.osuosl.org" emerge-webrsync |
| 112 |
|
| 113 |
The mirror should be whatever is listed first in /etc/make.globals, but that |
| 114 |
line right there guarantees you that you are getting the latest daily |
| 115 |
snapshot of the master rsync mirror from the master distfiles mirror. |
| 116 |
|
| 117 |
Regards, |
| 118 |
Jason Stubbs |
| 119 |
|
| 120 |
-- |
| 121 |
gentoo-security@g.o mailing list |
| 122 |
|
| 123 |
|
| 124 |
|
| 125 |
|
| 126 |
|
| 127 |
|
| 128 |
-- |
| 129 |
gentoo-security@g.o mailing list |
| 130 |
|
| 131 |
|
Archives