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

[Andreas Enge <andreas@enge.fr>]

On Fri, Aug 05, 2016 at 08:59:32PM -0400, Mark H Weaver wrote:
> 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.

I am not very happy about such a policy; if I sign a commit, I am only
signing my commit, and not all of its history, or even only its history
up to the previous signed commit. Also, while signing each commit is
a simple git configuration option, needing to verify the history before
each commit would be a hassle that as far as I can see is not easily
automated.

> 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.

Agreed, this mitigates the problem above. But I feel better with the
current situation.

Andreas