Storage internals: UUID

[Mark Grandi]

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

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

On Tue, Jun 12, 2012 at 4:06 AM, Daniel Carrera <dcarrera at hush.com> wrote:

>
>
> On Tuesday, June 12, 2012 at 2:39 AM, Mark Grandi <markgrandi at gmail.com>
> wrote:
> >
> > Does each revision store the parent revision's sha1 value? Cause it
> seems
> > looking at bzr testament --long, it only stores the sha1 values of each
> file at that
> > revision, the parent's revision id, and then all of that is used to
> compute that
> > revision's sha1 value. But say, a malicious attacker (like the
> attack on
> > kernel.org's servers not too long ago) tries to maliciously edit a
> file in a bazaar
> > repo. If they edit a file, then that won't necessarily be caught ,
> because it seems
> > the testament is computed every time (not saved anywhere),  and it
> doesn't look
> > like its saved in the child revision either, so there is no guarantee
> that the sha1 value
> > of any revision is the correct value. Am i right in thinking this?
> I'm kinda interested
> > in the security of a repo too, and seeing if you can verify that each
> revision is indeed intact by
> > tracing back  the testaments from the head to the null revision.
> > ~mark
>
> 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:
>
> 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).
>
> 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.
>
> Cheers,
> Daniel.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120612/d7e9d570/attachment.html>