Re: [PATCH] commit: teach --gpg-sign option

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 6, 2011, 21:29 UTC
Message-ID: <7v8voxzu5f.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111006171107.GA10973@elie>

Jonathan Nieder <jrnieder@gmail.com> writes:

>> I like this approach better than the prior "push certificate" idea.
>> The signature information is part of the history graph
>
> I probably missed some earlier discussion (so please forgive me this),

Heh, you are not forgiven when the original message has a clear pointer to the previous discussion ;-).

> but how is it intended to be used?  Would projects
>
>  a. require as a matter of policy that all commits be signed

Possible. Personally I would _not_ advise it but they can send in a patch to add a configuration or two if they do want to run their project that way.

>  b. just sign releases as usual, but as commits in the history graph
>     instead of tags

This is not meant to replace tags that is attached after the fact. If anything...

>  c. sign the occasional especially interesting commit

...with the definition of "interesting" being "this is tonight's tip of branch Linus is pushing out between releases", "I shortly will ask Linus to pull from the history leading up to this commit", etc., this is the primary scenario I personally envision the feature would be used in. Without having to have "nightly" signed tags that clutter the tag namespace, we can gain more confidence in the integrity of the history between officially tagged release points that may be a few months apart, depending on projects.

> ... How
> does this relate to the "push certificate" use case, which seemed to
> be mostly about authenticating published branch tips with signatures
> that are not necessarily important in the long term?

To the upstream project whose participants are signing its history, these publish points may not be important in the longer term, but for downstream consumers that have to fork from an in-between point for the next embedded device release track, it serves the same purpose as push certificates and is equally important: it allows them to limit the length of near-tip history that might have been tampered that needs to be validated. If the downstream consumers fork only from a signed commit point, they only need to audit their own history without worrying about imported stuff after incident like what k.org had recently.

I am also somewhat disturbed by "have to sign when committing, long before I am confident that this is worth pushing" aspect of this approach, but I do not think it would be much of an issue in practice.

 - If you are only pubishing one independent branch, it is just the matter
   of either "commit --amend --gpg-sign" or "commit --allow-empty --gpg-sign"
   before you push;

 - If you are publishing multiple related branches (e.g. maint, master,
   next) like I do, and want to correct a mistake discovered at a lower
   branch (e.g. master) after it has been already merged in higher
   branches (e.g. next), you have to either amend the tip of the lower
   branch and rebuild the higher branches, or queue a fix-up to the tip of
   the lower branch and merge the result to the higher branches _anyway_,
   before you push.