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