git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: dwh@linuxprogrammer.org
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org
Subject: Re: Is the sha256 object format experimental or not?
Date: Thu, 13 May 2021 16:47:06 -0700	[thread overview]
Message-ID: <20210513234706.GG11882@localhost> (raw)
In-Reply-To: <20210513204957.5g76czb5bk3thlep@meerkat.local>

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.

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

  reply	other threads:[~2021-05-13 23:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  2:22 Preserving the ability to have both SHA1 and SHA256 signatures dwh
2021-05-08  6:39 ` Christian Couder
2021-05-08  6:56   ` Junio C Hamano
2021-05-08  8:03     ` Felipe Contreras
2021-05-08 10:11       ` Stefan Moch
2021-05-08 11:12         ` Junio C Hamano
2021-05-09  0:19 ` brian m. carlson
2021-05-10 12:22   ` Is the sha256 object format experimental or not? Ævar Arnfjörð Bjarmason
2021-05-10 22:42     ` brian m. carlson
2021-05-13 20:29       ` dwh
2021-05-13 20:49         ` Konstantin Ryabitsev
2021-05-13 23:47           ` dwh [this message]
2021-05-14 13:45             ` Konstantin Ryabitsev
2021-05-14 17:39               ` dwh
2021-05-13 21:03         ` Junio C Hamano
2021-05-13 23:26           ` dwh
2021-05-14  8:49           ` Ævar Arnfjörð Bjarmason
2021-05-14 18:10             ` dwh
2021-05-18  5:32         ` Jonathan Nieder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210513234706.GG11882@localhost \
    --to=dwh@linuxprogrammer.org \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).