On Thu, May 13, 2021 at 04:47:06PM -0700, dwh@xxxxxxxxxxxxxxxxxxx wrote: > On 13.05.2021 16:49, Konstantin Ryabitsev wrote: > > Check out what we're doing as part of patatt and b4: > > https://pypi.org/project/patatt/ > > > > It takes your keyring-in-git idea and runs with it -- it would be good to have > > your input while the project is still young and widely unknown. :) > > Konstantin: > > That's really clever. I especially love how you're using the list > archive as the provenance log of old keys developers used. That seems > like it would work although I have worries about the security of > X-Developer-Key and the lack of key history immediately available to > `git log` because it's in the list archive and not in the repo directly. > > I guess the old keys would still be in your local keyring for `gpg` to > use but it would mark signatures created with old revoked keys as > invalid even though they are valid. Thanks for taking a look at it. I don't view this as much of a problem, since the goal for the project is specifically end-to-end patch attestation. For git commits, if they are signed with a key from the in-git keyring, it would actually be really straightforward to get the valid key at the time of signing -- you just retrieve the keyring using the date of the commit. > My approach has been to move to cryptographically secure provenance logs > that contain key rotation events and commitments to future keys and also > cryptographically linking to arbitrary metadata (e.g. KYC proofs, etc). > The file format is documented using the Community Standard template from > the LF. I'm hoping to move Git to use external tools for all digest and > digital signature operations. Then I can start putting provenance logs > into a ".well-known" path in Git repos, maybe ".plogs" or something. > Then I can write/adapt a signing tool to understand provenance logs > of public keys in the repo instead of the GPG keyring stuff we have > today. > > Provenance logs accumulate the full key history of a developer over > time. It represents a second axis of time such that the HEAD of a repo > will have the full key history, for every contributor available to > cryptographic tools for verifying signatures. This makes `git log > --show-signature` operations maximally efficient because we don't have > to check out old keyrings from history to recreate the state GPG was in > when the signature was created. Hmm... I'm not sure if it's an inefficient operation in the first place. If the keyring is in the same branch as the commit itself, then you can retrieve the public key using "git show [commit-sha]:path/to/that/pubkey". If it's in a different branch, then it's slightly more complicated because then you have to find a keyring commit corresponding to the commit-date of the object you're checking. In any case, these are all pretty fast operations in git. > I still like your approach purely for the "it works right now" aspect of > the solution. Good job. I can't wait to see it in action. As you know, this is my third attempt at getting patch attestation off the ground. The first one I implemented using detached attestation documents and it was clever and neat, but it was too complicated and failed to take off -- I think mostly because a) it wasn't easy to understand what it's doing, and b) it required that people adjust their workflows too much. The second attempt was better, but I think it was still too complicated, because it required that we parse patch content, making it fragile and slow on very large patch sets. I'm hoping that this version resolves the downsides of the previous two attempts by both being dumb and simple and by only requiring a simple one-time setup (via the sendemail-validate hook) with no further changes to the usual git-send-email workflow after that. I've not yet widely promoted this, as patatt is a very new project, but I'm hoping to start reaching out to people to trial it out in the next few weeks. Thanks, -K
