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

[Junio C Hamano <gitster@pobox.com>]

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.