On 19/05/06, Patrick Lauer <[EMAIL PROTECTED]> wrote:
On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote: > There are now several hundred gentoo developers. It is more likely > that one of them has a security lapse than cvs.gentoo.org. One is a "local" bug, the other one "global". I'd prefer a system that is resilient against two devs going crazy - right now the "right" persons could stage a manipulation that would be hard to detect and where your (single central) signature fails quite nicely.
Realistically, you have to trust the gentoo devs. The only system that won't fail against the rogue developer threat is to have multiple sign-off on commits. Most developers don't want that. Even if it were required, it would only raise the bar slightly - all a rogue developer would have to do is to establish a new id, fix some bugs, and "recruit" themselves.
It's very coarse - Yes / No
Doesn't tell you what failed how ... so I DoS it by inserting one bit on any rsync mirror and it will "fail". You don't know what fails where ...
You can't upgrade and you don't know what fails where ... Right, but ... what caused the error?
It doesn't matter which bit in which file was changed - if an attacker has access to corrupt the tree, then the whole tree is suspect and can't be trusted. From a users point of view - they don't care what caused the error, they just sync again with a different server.. From a developers point of view - you can just diff the corrupt server against your local tree and look for exploit code.
> It could be done in stages. Start with the (easier) central key, then > later add distributed keys. I think a hybrid system would be the ideal > system, but realistically, bug #5902 has been around since March 2003 > and no real progress has been made. That bug appears quite unrelated to me ... how does FEATURES="userpriv" relate to signing?
#5902 is "emerge security - running as root and digital signatures". Digital signatures have something to do with signing ;-) Actually, the bug has been open since August 2002...
> The main sticking point seems to > be disagreements over key management and policies. I would hope that > most people could agree that a single key with a post-commit signing > is better than what we have now, debatable
It's debatable that a centralised signing the tree is better than not having any security at all?
> and could be easily implemented, yes > whilst leaving open the option of a hybrid system implementation at a > later date. yes but that's not a cure. You'd have to sign _each file_ to get a reasonable tampering detection, or at least per-directory. You add a single point of failure and give attackers a high-profile target.
It depends... what is the purpose of signing individual files? If it's to find the point of corruption, then you can just diff the corrupt tree against a good one and look for any exploit like code. Look at it this way - when emerge detects a corrupt tar.gz in distfiles, it doesn't tell you exactly what file in the package is corrupt. It just downloads it from someplace else. The same principle can be applied to the portage tree. I'm open to the possibility of signing every file/directory individually if there's a good reason, but I don't see one at the moment. -- [email protected] mailing list
