Storage internals: UUID

Mark Grandi markgrandi at gmail.com
Tue Jun 12 00:38:18 UTC 2012


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

On Fri, Jun 8, 2012 at 12:10 AM, John Arbash Meinel
<john at arbash-meinel.com>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/8/2012 1:34 AM, Neil Martinsen-Burrell wrote:
> > On Thu, Jun 7, 2012 at 6:15 PM, Daniel Carrera <dcarrera at hush.com>
> > wrote:
> >
> > [...]
> >
> >> bzr update -r 165c2a8
> >>
> >> bzr branch -r165c2a8
> >>
> >> etc.
> >>
> >> You get the idea. As in other VCS's, you don't have to enter the
> >> entire SHA1 as long as what you provide is unique. I think it
> >> would be cool if at every place where you normally insert a
> >> revision id, you had the option of entering the SHA1 of the
> >> testament instead. For my daily work I would use the convenient
> >> "-r 5" type revision number, but when I publish a release, I
> >> would probably give instructions based on the hash.
> >>
> >> In addition, with this feature you would add one more "workflow"
> >> choice for Bazaar. People who actually prefer to refer to
> >> revisions by hash (perhaps refugees from Git or Hg) have an
> >> option to continue working just the way they like it, and have
> >> basically the same cryptographic assurance that they get from Git
> >> and Hg.
> >>
> >> What do you think? Do you think this is doable? Easy?
> >
> > Bazaar has a facility for defining new "revisionspecs" in plugins.
> > This means that you could define a way to specify revisions using
> > the "-r sha:165c2a8" syntax. See the code in bzrlib/revisionspec.py
> > for examples of how the existing "-r <type>:" revision specs work.
> > The important method to define in your subclass of RevisionSpec is
> > RevisionSpec._as_revision_id(self, context_branch).  Then,
> > register your class with
> > bzrlib.revisionspec.revspec_registry.register('sha',
> > revspec_subclass).
> >
> > -Neil
>
> You certainly could, with the major caveat that unless you index the
> value it is going to be *terribly* slow to recompute the testament for
> every revision just to figure out which one matches the sha: you provided.
>
> So while code to add a revision spec is pretty small, doing the
> indexing is non-trivial. (Probably not terrible, just need a
> post-branch-tip-changed hook to update your cache, and look it up in
> the revision spec code.)
>
> John
> =:->
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk/RpXAACgkQJdeBCYSNAAPUnwCghhi9jMZOb7YHbluWaHmmCLDc
> czMAnjuJT0csikzEIBZyLwebjdUgKKwh
> =BpKS
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120611/f8467910/attachment.html>


More information about the bazaar mailing list