On Tue, 2006-01-10 at 23:57 -0500, Andrew Muraco wrote: > What I meant to say is, having this alternative tree method (as > described here) would mean that portage would handle everything the > exact same as it already does, which means that if someother tree was > accidently sync'd or replaced the local one, portage would react and > want to update everything, because its not 'aware' that there is a > difference in the first place. (now that I think about it, how likely is > it that something like that will happen?)
So someone would "accidentally" change the SYNC variable, then "accidentally" run "emerge --sync"? That seems rather unlikely. > The method described here would also open up the oppurtunity for "fake" > enterprise trees, without having something to double check that the tree > that we have is indeed the one that is wanted, it would be possible for > a hacked rsync server (or a bogus one) to host the enterprise (stable) > trees with extra ebuilds which could compromise security (/me thinks of > emails warning about Microsoft's patchs and links which point to > infectious websites.) What exactly makes the release trees any more vulnerable to this than current portage? > Maybe this is something thats not very likely to happen, but it still is > important to note that an enterprise tree has to be secure. You will notice that I *never* call it an "enterprise" tree, so don't make that mistake yourself. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
