[Whonix-devel] git log --pretty="format:%H$t%aN$t%s$t%G?" --show-signature

[Junio C Hamano]

Mike Gerwitz <mikegerwitz at gnu.org> writes:

> It has since improved; I'm looking for the time to update the article,
> or write a follow-up.

Thanks for an amusing read.  We also let you merge a signed tag
these days, so that in a variant of your merge scenario #2, your
merge commit can carry your GPG signature, made when you do the "git
merge -S $other_history" to merge $other_history you obtained from
your trusted colleague, as well as the signed tag your trusted
colleague made with her GPG signature.  That way, upon seeing that
merge, a third-party can verify that the merge was made by you, and
also the history of the side branch integrated to your history with
that merge is vouched by your trustred colleague.

I am however not quite sure what conclusion you are trying to drive
at by contrasting approaches #2 and #3.  The perceived problem of
approach #2, if I am reading you correctly, is that the merge is
what you vouch for but the commits on the side branch are not signed
so there is no way for you (as the merge creator) to point fingers
to when the result of the merge turns out to be problematic.  The
argument for approach #3 would be that it would give you (as the
merge creator) somebody to point fingers to if you forced others who
ask you to pull from them to sign their commits.

But I am not sure if that is the right way to look at the bigger
picture.

Imagine you are working on a project with two branches, maint and
master.  The policy adopted by the project is to use the maint
branch to prepare for the next maintenance release, which should
never add new features.  New features are to be merged to master
for the next feature release.

And imagine that you made a mistake of merging somebody else's
branch that adds a new feature, which happens to be perfectly done
and introduces no bug, to the maint branch.  Your merge is signed by
your GPG key.

Does it absolve you from blame if you can say with certainty (thanks
to GPG keys on them) that those commits on the side branch that adds
unwanted (from 'maint' policy's point of view) new feature were made
by somebody else, because the project used the approach #3?

Not really.

How would that case be any different from the case where the side
branch you merged were buggy or even malicious?  After all, your GPG
signature carries more weight than "Yes, I did this random merge but
I did so without thinking about what damage it causes to the history
by pulling in other peoples' changes".  Or at least it should carry
more weight to your users who trust a history having your GPG
signature.  "This history is coming from Mike whom we trust" is what
your users expect, no?  When you sign your merge with "merge -S",
you are vouching for the contents of the whole tree, not just "I
made this merge, but I don't have anything to do with what it pulled
in."  It does not really matter to the end users where the changes
came from.  You are certifying that "git diff HEAD^ HEAD" after
making the merge is what you are pleased with by signing the merge.

Having said that, what approach #3 (or merging a signed tag) does
give you as the merge creator is a distrubution of trust.  You may
not have to be _so_ careful verifying "git diff HEAD^ HEAD" of the
merge when you know you can trust the side branch you are merging
into your history was done by somebody you trust.

But ultimately, the responsibility lies on the person who creates
the topmost merge and advances the tip of the history the users of
the end product of the project considers the authoritative one.