Verifiable repository integrity

[Christian Helmuth]

Hi everybody,

some days ago, the Genode Labs team had a coffee break discussion
about possible means for developers to verify the integrity of the
official Genode repository. In the following, I want to explain the
current state and put up for discussion what could be improved with
some effort.

In November 2011, our Git repository on GitHub superseded the
Sourceforge Subversion repository and tar archives as main source-code
distribution channel. The release history is easily replicable by
following Git tags. In 2012, we had a discussion in our issue tracker
[1] about signing the release tags and integrated this step in our
work flow shortly after. As a result the integrity of a release can be
checked by verifying the corresponding Git tag since Genode 12.05. At
this time, the interest into our Sourceforge archives already almost
vanished, so we never bothered to apply these integrity measures there
too.

In the above-mentioned discussion, someone brought up Git's support
for "signed commits" from the background that each release adds about
250 commits to the repository in three months. This is also the reason
why more and more developers intrepidly base their work on the Genode
master branch. With signed commits in place, developers may always
verify the integrity of the upstream repository revision used (see [3]
for an article about Git signed commits). To me this sounds tempting
and represents the natural continuation of our open development
history.

Our current work flow includes two branches of the Genode repository:
staging and master. The complete rationale can be found in Section
5.5.1 of [2]. The staging branch is the entrance hall for all
contributions to Genode from the community and the core team members
alike. Bug fixes, topic branches, and other improvements have to pass
our nightly autopilot testing and a thorough review by Norman and me
on staging before entering our master branch. As we apply the Git
rebase work flow the master history is a linear series of commits with
no parallel development branches and merge points. Before a batch of
commits from staging is added to master original commits and potential
fixup commits are squashed into reasonable commits for master.

The work flow explained above does not support the preservation of
commit signatures by the author of the original commit because of
cherry-picking and potential squashes. Also, the integrity of the
master branch is more "you get what the core team reviewed" than "this
is what the author committed originally". In my opinion a batch of
commits should be signed by the reviewer when added to the master
branch. Unfortunately, the Git tool itself does not include an easily
usable tool for signing all commits of such a batch before pushing the
updated master branch. But, we could sign just the head of batch and
get a verifiable update step with

  git commit --gpg-sign --amend --no-edit && git push origin HEAD:master

Among other options the signatures can be checked by

  git log --show-signature

and the head of master would always show "gpg: Good signature...".

Does this proposal make sense to you resp. does the explained
approach represent the intended improvement for developers caring
about upstream repository integrity?

[1] Issue 138 https://github.com/genodelabs/genode/issues/138
[2] Genode Foundations http://genode.org/documentation/genode-foundations-15-05.pdf
[3] https://mikegerwitz.com/papers/git-horror-story

Regards
-- 
Christian Helmuth
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth