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