Storage internals: UUID

[Mark Grandi]

Yeah, thats basically what I was saying

On Tue, Jun 12, 2012 at 6:11 PM, Daniel Carrera <dcarrera at hush.com> wrote:

>
> In either case, you can detect a corrupt tree, but only if you have a copy
> of the correct ID or testament. If you don't have a copy of the SHA1 hash
> from a source that you trust, you can just as easily get a malicious tree
> from Hg / Git as you can from Bzr... That said, there is one thing that Hg
> / Git can detect that a testament can't: A change to the history that in
> the end leaves the repository intact. Imagine that you have a repository
> with the following revisions:
>
> A -> B -> C -> D -> E -> F
>
>
> Imagine that after "A" I insert a malicious revision "Q". The tree will
> look like this:
>
> A -> Q -> B* -> C* -> D* -> E* -> F*
>
> The '*' denotes the fact that the testament is different, so the insertion
> is detectable. Now imagine that after 'C*' I insert another revision "R"
> that changes back all the changes made by "Q", completely removing the
> inserted code. Now the repository will look like this:
>
>
> A -> Q -> B* -> C* -> R -> D* -> E -> F
>
> In revision D* you can still recognize that something went wrong because
> the revision id of the parent is not the same as that of revision "D". But
> after that, revisions E and F are indistinguishable from those of the
> original history. In this way, Hg and Git protect the integrity of not only
> the tree, but also the history leading up to it (assuming that you don't
> rebase, which I think Git people do often).
>

yeah this is basically what I was thinking. It almost seems that this could
be solved in bzr (giving bzr the same ability to check the  integrity of
the HISTORY of the tree) is to just make a new testament revision (revision
1.1 or something) and just include the SHA1 of the parent revision, I'm not
sure if thats a trivial thing to do, or the effects of that, l(ike if two
revisions are merged together, what is the resulting revision's parent?)
but it seems to be like a simple fix for this problem that one revision
doesn't have any assertions about the revisions that came before it. And as
a result it would make the previously discussed plugin about making a
revisionspec for sha1 hashes a lot easier since revisions could
theoretically store their final sha1 hash in the revision itself and it
would be a lot faster to search on that rather then computing it every time


>
> > Gpg signatures seem like those would work fine, but then how does
> > anyone verify which gpg key is the right one?
>
> This can be as simple or as complex as you want to make it... For example,
> you could post it everywhere so that at some point "everyone" knows your
> GPG key and there's no feasible way for someone to hack the server with
> your website, and your facebook account, and all the signatures in the
> mailing list archive that contain a copy of your key... For the more
> paranoid, you could wait to meet me in person and ask for two pieces of ID
> including a passport before agreeing to accept the piece of paper I'm
> handing to you as an accurate copy of my GPG key... Somewhere in between,
> you can rely on the web of trust system. People hold "key signing parties"
> where they verify each other's GPG keys and sign them, and they build a
> network. The web of trust works somewhat like this:
>

I know how gpg works, sorry if you misunderstood my question, but what
happens if my commiter email is 'mark at example.com', i create a gpg key with
that email and sign my commits, now evil bob, also creates a gpg key with
my email address, and then he can theoretically resign the signature text
and it would be valid with HIS key, but not mine, im just confused on what
happens since the only identifier in the signature text is the email, does
gpg just use the email to choose what key to use, and it would use the real
one (the one that is trusted) and fail on the one that was signed with a
different key?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120612/aa045cfb/attachment.html>