Author: Peter Todd 2014-08-23 14:32:15
Published on: 2014-08-23T14:32:15+00:00
In a discussion about Git and Mercurial commits, Troy Benjegerdes suggests cloning Git to Mercurial as the latter is designed around immutable commit history. However, for communication purposes, mutable commits are necessary. The author states that while immutable commits make sense for recording public history, it is rare for the way some functionality is developed to be the best sequence of changes for other developers to understand why and what has been changed. Mercurial may assume immutable history, but an attacker can fake series of Mercurial commits just as easily as they can with Git commits. The author suggests that signed commits and timestamps protect against history rewriting. The author also points out the problem with Github, stating that it is too tempting to approve changesets via the web page that is not PGP-signed, especially in a rush to get the latest OpenSSL 0day security patch build released. Multiple redundant 'master' repositories run by different people in different jurisdictions should be implemented to avoid this problem. The easiest way to achieve this is to have a formal program of code review, perhaps on a per-release basis, that reviews the diffs between the previous release and the new one. Master repos in this scenario are copies of the "master master" repo that someone has manually verified and signed-off on, with a PGP signature. Finally, the author provides a useful template for those who feel like volunteering to maintain one of these repos, which is their Litecoin v0.8.3.7 audit report.
Updated on: 2023-06-09T02:22:07.055556+00:00