Re: Is the sha256 object format experimental or not?

From: dwh@linuxprogrammer.org <dwh@linuxprogrammer.org>
Date: May 13, 2021, 23:47 UTC
Message-ID: <20210513234706.GG11882@localhost>
In-Reply-To: <20210513204957.5g76czb5bk3thlep@meerkat.local>

On 13.05.2021 16:49, Konstantin Ryabitsev wrote:

Show 5 quoted lines

>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.

Old keys--even if revoked or compromised--matter in a world of digitally signed data. As a matter of course, people should rotate their signing keys on a regular basis. It's just good hygiene. That means that there will always be old data signed with old keys and those old keys need to be kept around to validate the old signatures.

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.

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.

Cheers! Dave