On Sun, Jul 8, 2018 at 1:50 PM Kristian Fiskerstrand <k...@gentoo.org> wrote: > > On 07/08/2018 07:34 PM, Rich Freeman wrote: > > The patch is to do the verification before > > checking it out so that if it fails the tree is left in a > > last-known-good state (at least as seen by tools at the filesystem > > level - the fetched bad commits would still be visible to git). > > there is still a very different key management issue discussed. If a > developers credentials are removed from Gentoo LDAP for some reason it > will be stopped from pushing new commits immediately, but the third > party verification can be valid up until that point and after since the > developer might not have published a revocation certificate. > > the git sync method will need a way to distinguish this for end-users, > but the proper rsync synchronization will be able to trust the data at > the point we say it is OK.
Again, the current portage support for git verification doesn't check any developer keys. It just checks the keys in /usr/share/openpgp-keys/gentoo-release.asc (after fetching updates). If the HEAD commit verifies, it is good, if not it is bad. It doesn't matter whether any commit in the tree other than the HEAD has a valid signature, and it will reject any signature from a developer on HEAD. The logic is somewhat similar to rsync in that regard. There is a separate proposal out there which is unimplemented to check developer keys, and we aren't talking about that. I agree that it has the challenge of figuring out whether the key was acceptable at the time the signature was made. -- Rich
