On Mon, Jul 2, 2018 at 7:57 PM Rich Freeman <ri...@gentoo.org> wrote: > This only helps you if a dev you don't trust is compromised. If a dev > you trust is compromised, they can modify anything in the tree and > you're hosed.
Yes indeed. This is more or less what we're aiming for. Putting the trust in developers. The goal is for infra not to be the weak link in this, as it currently is. > Sure, I'd prefer to not extract git signatures and just distribute via > git purely without any rsync. Yea, I personally don't really care much for rsync either. I've just kind of been assuming this is a requirement of any gentoo solution. But maybe this whole thing should take another dimension, and we should instead talk about sunsetting rsync, and moving to a model of: 1) git fetch, 2) git verify, 3) git checkout? There still might be problems with "untrusting" devs, as I wrote above, but perhaps there's room to grow within the git framework, by manually filtering commits during checkout, or even by imposing ebuild directory signature-based ACLs that I think you were hinting at before. So, sure, if you want to call for an abolition of rsync, maybe I'd follow you in that direction instead of the one here I'm proposing. > > Sure, but since any developer can change any file, that is basically > the same thing. If somebody steals a single dev's key they can just > rootkit any file of their choosing, sign that one change, and it will > slip through any of these methods. The only protection against that > is tracking who is allowed to touch what files, and then you're still > hosed if a dev for a widely-used file gets their key stolen. As stated above, yes, this is the intended model. And I think it's considerably better than the current state of affairs. The threats get even less scary as we convince Nitrokey or Yubikey to send all gentoo developers free devices, and then mandate keys remain on those devices and never get copied, etc etc.
