Re: [git patches] libata updates, GPG signed (but see admin notes)
- From
Robin H. Johnson <robbat2@gentoo.org>
- Date
- Nov 3, 2011, 03:16 UTC
- Message-ID
- <robbat2-20111103T030225-511273733Z@orbis-terrarum.net>
- In-Reply-To
- <20111103025532.GB9492@sigill.intra.peff.net>
On Wed, Nov 02, 2011 at 10:55:32PM -0400, Jeff King wrote:
> But big projects that are interested in signatures probably want to say > more. They want to say "this developer really wrote this commit". They > want to say "QA passed this commit". They want to say "the history up to > here looks good". And so on.
On the Gentoo side, we've also pondered the question of: author != committer != pusher And how to preserve many signatures from sources.
We're on a central repo model, with some ~250 committers.
I was originally primarily after the push certificates/signed-push, and recording that data in the notes, but that still has the problems of third-party verification as mentioned in the thread.
If we require that the tip of every push is a signed commit via a hook, we get knowledge of the pushers. Either your real commit itself is signed, or you have a signed merge commit on top, or you have a signed empty commit. In all of the cases, I can verify your signature at the recv hook. Having signed push in this case has a benefit that you could ship the data as a bundle, or async from the signing.
The QA value of multiple signatures per commit is also valuable, to assert SOB WITHOUT altering the commit. I see spearce's rant and the retort, and really think there needs to be a middle ground - some of commits that are coming from pulls, and not getting additional SOB, could really benefit from them being recorded (I see them on mailing lists, but not introduced since that would break 'stable' IDs).
Show 7 quoted lines
> But they can't say those things without binding some data to the commit > (i.e., making a certificate saying "this commit passed QA"). Data which > might only make sense to assert much later than the commit is written. > > So you're going to need to support detached commit signatures in some > form anyway to make everybody happy. Which isn't to say in-commit > signatures are wrong, but they are just one tool in a toolbox.
I was proposing that Git supports _all_ of these models: - signed commits - signed pushes (via certs) - whatever signed lightweight tag idea happens - existing annotated tags
Choices. Each with their own costs and advantages.
-- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85