<div>Yeah, that makes sense. However, in the git and hg side, it seems that the hashes are chained, so revision 2 has the revision id of revision 1 as part of the sha1 hash, so thats easy to verify all the way back to the root of the tree, unless you rebase it (which someone talked about earlier on in this thread, about how rebasing can give a commit a new id), so i don't see how someone can change a commit in a git repo without effecting the revision ids of everything that comes after it, or just not modifiying the revision id and a simple check would catch that<br>
</div><div><br></div><div>But since bzr doesn't chain their hashes, it seems that the only way to verify that a branch hasn't been tampered with is to store the hashes somewhere else as a trusted third party like you said. Gpg signatures seem like those would work fine, but then how does anyone verify which gpg key is the right one? Whats stopping someone from using the same email as someone else in the repository, creating a key that matches that email and then resigning the malicious commits, or any future commits with that email? Not to mention that its not a requirement to sign commits anyway, so any unsigned ones are not protected at all</div>
<div><br></div><div class="gmail_quote">On Tue, Jun 12, 2012 at 4:06 AM, Daniel Carrera <span dir="ltr"><<a href="mailto:dcarrera@hush.com" target="_blank">dcarrera@hush.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Tuesday, June 12, 2012 at 2:39 AM, Mark Grandi <<a href="mailto:markgrandi@gmail.com">markgrandi@gmail.com</a>> wrote:<br>
><br>
> Does each revision store the parent revision's sha1 value? Cause it seems<br>
<div class="im">> looking at bzr testament --long, it only stores the sha1 values of each file at that<br>
</div>> revision, the parent's revision id, and then all of that is used to compute that<br>
> revision's sha1 value. But say, a malicious attacker (like the attack on<br>
> <a href="http://kernel.org" target="_blank">kernel.org</a>'s servers not too long ago) tries to maliciously edit a file in a bazaar<br>
> repo. If they edit a file, then that won't necessarily be caught , because it seems<br>
> the testament is computed every time (not saved anywhere), and it doesn't look<br>
<div class="im">> like its saved in the child revision either, so there is no guarantee that the sha1 value<br>
</div>> of any revision is the correct value. Am i right in thinking this? I'm kinda interested<br>
<div class="im">> in the security of a repo too, and seeing if you can verify that each revision is indeed intact by<br>
> tracing back the testaments from the head to the null revision.<br>
> ~mark<br>
<br>
</div>The issue is not so much whether you store the SHA1 values or whether you include the parents revision too. This can be hacked too. If an attacker has access to the server he could rewrite the file with the stored SHA1 values (in the proposed case for Bzr) or it could replace a revision and re-apply all the subsequent hashes (in the case of Hg / Git) or it could just add a new patch on top (again, Hg / Git). The only thing that makes these methods secure is one of the following:<br>
<br>
1. You could obtain the correct SHA1 from a third party... a trusted source, physically separate from the main server. For example, you could verify the copy on the server against the one on your computer (and the SHA1 makes this very easy and reliable).<br>
<br>
2. Alternatively, you could sign all your revisions with GPG, or maybe just the releases and publish the signatures on the same server. An attacker will not be able to replicate the signatures. If people check the signatures you are fine... A slight variation of this is Monotone, which makes you always sign your revisions but they don't use GPG as an external dependency. Monotone has implemented signatures on its own.<br>
<br>
Cheers,<br>
Daniel.<br>
<br>
</blockquote></div><br>