Re: ‘core-updates’ merge is a squashed commit

[Leo Famulari <leo@famulari.name>]

On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote:
> Leo Famulari <leo@famulari.name> writes:
> > If I push A-B-C with a signed HEAD immediately after somebody pushes a
> > forged D, won't it look like I vouch for D?
> 
> This can't happen unless D is already in your local repo before you
> commit locally.  If someone pushes D immediately before you try to push
> A-B-C, your push will be rejected.  At that point, you need to pull,
> rebase on top of D, and try again.  You can always see the ancestor
> commits before signing the new comit.
> 
> I haven't thought deeply on this, but it seems to me that Andy's
> suggestion has a lot of merit.  We could choose to decide, as a matter
> of policy, that if you sign a commit with unsigned ancestor commit(s),
> you are effectively vouching for those ancestor commits.  We could
> modify the commit hook to accept a push as long as the new HEAD commit
> is signed by an authorized key, disregarding the ancestors.
> 
> There's one thing that each of us would need to be careful of, though.
> If we adopt this policy, then before signing a commit, we'd need to
> first verify that the parent commit has been signed, lest we
> accidentally vouch for an unsigned commit that we know nothing about.
> 
> In practice, this could only happen if Savannah is compromised or
> there's a man-in-the-middle attack, because Savannah is supposed to
> ensure that pushes with unsigned HEADs are rejected.
>
> What do you think?

Okay, I think your analysis is right. If the HEAD of a push is always
signed, and that policy is known, then it is possible to know who is
responsible for pushing each commit.

But, I also think the primary point of signing the commits is to record
the identity of the person responsible for the commit, and so I think
the policy should be to sign each commit. [0]

The identity information provided by a "sign the HEAD" system seems
relatively brittle to me.

Somebody looking at a clone of the Git repo may not know about a commit
hook, or a "be careful" policy, that may or may not have been
consistently active (it seems that hooks don't come with `git clone`).
This person won't be able to easily attribute the unsigned commits.

Isn't it better for the identity information to be inherent to the Git
commits themselves, since those are what is preserved by Git? Git does
not preserve hooks or policies.

Also, is there some problem with signing each commit? I don't know why
we'd want to stop doing this.

[0] But, I also think that the hook we put in place to enforce this is
going to have to be modified, at least until we no longer need to push
this last batch of unsigned commits. At the very least, it should be
made to actually verify the signatures.