Re: [Monotone-devel] The dark side of content addressing

[Nathaniel Smith]

On Mon, Mar 06, 2006 at 12:40:33PM +0100, Jon Bright wrote:
> My intuition said that too - but then I remembered the big discussion 
> about Graydon not liking GUIDs, back when we were originally discussing 
> revisions.  An alternative, which sticks with a kind of 
> content-basedness, might be to take the hash of the branch name.
> 
> Upside: no reliance on availability and reliability of entropy.
> Downside: still content based, you get the same problem if Alice and Bob 
> name their branches the same way.
> 
> Introducing this kind of randomness might also have some implications 
> for test repeatability?

Huh, interesting idea.  This is less objectionable than, e.g., GUIDs
for files, because those introduce exciting new failure modes, that
you can't even check for; the worst that can happen with this is that
a malicious(?) person can... branch off of a revision they already
know the contents of, but _without using the branching commands_.  Oh
my.  Or I guess failures in the RNG could cause such things to happen
by accident, but it's still really not a dangerous failure.

There is definitely something to be said for determinism, though!  I
just realized the other day that if we want to introduce these things
in 'rosterify' (or the like), then we _have_ to make it deterministic
somehow, or else we break rosterifying of private branches... which a
number of people have requested for 0.26.  In that case, though, we
could, for instance, just use the id the rev had before
rosterification, as the new salt.

I'm not off-hand thinking of any similarly horrible consequences to
using actual randomness for future imports, but that doesn't mean
there aren't some... like you mention, maybe testing would be easier.

A nice thing about using a hash, is that nothing downstream has to
care how it was generated; one can change strategies over time.  To
make sure of this, one definitely _should_ though put some sort of
version marker into the content being hashed... e.g., have it start
with a uleb128 number or something, and increment it with each change
in generator function, to avoid conflicts.  (Cf. GUID version bits.)

> Overall, I can't immediately think of any security problems with the 
> current behaviour -- and by implication, no problems of the 
> branch-name-based-initial-revision-hash occur to me either.  Might using 
> the hash of the branch name be a better way to go?

Right, I can't see how this affects the security properties of
anything; we never depended on each call to setup creating a unique
rev or anything.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."