On Sat, Jul 7, 2018 at 1:34 AM Martin Vaeth <mar...@mvath.de> wrote: > > Rich Freeman <ri...@gentoo.org> wrote: > > > > Biggest issue with git signature verification is that right now it > > will still do a full pull/checkout before verifying > > Biggest issue is that git signature happens by the developer who > last commited which means that in practice you need dozens/hundreds > of keys.
This is untrue. The last git signature is made by infra or the CI-bot, and this is the signature that portage checks. Portage will NOT accept a developer key, or any other key in your keychain, as being valid. It will, of course, not work on the regular git repo used for committing for this reason. You need to use a repo that is signed by infra (which typically includes metadata/etc as well). I'll trim most of the rest of your email and only reply to significant bits, because you seem to not understand the point above which invalidates almost everything you wrote. The concerns you raise would be an issue if you were checking individual developer keys. > > So currently, it is impossible to do *any* automatic tree verification, > unless you manually fetch/update all of the developer keys. > As noted, you don't need to fetch any developer keys, and if you do fetch them, portage will ignore them. > > > unless you stick --force in your pull > > Unfortunately, it is not that simple: git pull --force only works if > the checked out tree is old enough (in which case git pull without --force > would have worked also, BTW). You completely trimmed the context around my quote. I was talking about the malicious commits in the recent attack. They were force-pushed, so it doesn't matter how complete your repository is - they simply would not be pulled without --force. You seem to be providing advice for how to do a pull with a shallow repository, which I'm not talking about. > > Honestly, I think git is a good fit for a lot of Gentoo users. > > At least since the ChangeLogs have been removed. > IMHO it was the wrong decision to not keep them in the rsync tree > (The tool to regenerate them from git was/is available). Changelogs are redundant with git, and they take a ton of space (which of late everybody seems to be super-concerned about). I don't get that on one hand people get twitchy about /usr/portage taking more than 1GB, and on the other hand they want a bazillion text files dumped all over the place, and as a bonus they want them prepended to instead of appended so that rsync resends the whole thing instead of just the tail... But, this was endlessly debated before the decision was made. Trust me, I read every post before voting to have them removed. > > > it is different, but all the history/etc is the sort of thing I think > > would appeal to many here. > > Having the ChangeLogs would certainly be sufficient for the majority > of users. It is very rare that a user really needs to access the > older version of the file, and in that case it is simple enough > to fetch it manually from e.g. github. It is very rare that somebody would want to use Gentoo at all. My point is that the sorts of people who like Gentoo would probably tend to like git. But, to each their own... > > > Security is obviously getting a renewed focus across the board > > Unfortunately, due to the mentioned keys problem, git is > currently the *unsafest* method for syncing. The "keys problem" has nothing to do with the security of git verification, because those keys are not used by git verification on the end-user side. An infra-controlled key is used for verification whether you sync with git or rsync. Either way you're relying on infra checking the developer keys at time of commit. Now, as I already mentioned git syncing is currently less safe due to it doing the checkout before the verification, and they are in the process of fixing this. > (BTW, due to the number of committers the portage tree has a quite > strict policy w.r.t. forced pushes. Overlays, especially of single > users, might have different policies and thus can fail quite often > due to the "git pull" bug.) It probably should be a configurable option in repos.conf, but honestly, forced pushes are not something that should be considered a good practice. There are times that it is the best option, but those are rare, IMO. -- Rich
