Re: Mercurial 0.4b vs git patchbomb benchmark

[Tom Lord]

  > ie does mercurial do distributed merges, which git was designed for, and 
  > does mercurial notice single-bit errors in a reasonably secure manner, or 
  > can people just mess with history willy-nilly?

  > For the latter, the cryptographic nature of sha1 is an added bonus - the
  > _big_ issue is that it is a good hash, and an _exteremely_ effective CRC
  > of the data. You can't mess up an archive and lie about it later.

On the other hand, you're asking people to sign whole trees and not just at
first-import time but also for every change.

That's an impedence mismatch and undermines the security features of the
approach you're taking and here is why:

I shouldn't sign anything I haven't reviewed pretty carefully.  For
the kernel and in many other situations, it is too expensive to review
the whole tree.  Thus, the thing actually signed and the thing meant
by the signature are not equal.  I sign a tree, in this system,
because I think the right diffs and only the right diffs have been
applied to it.   My signature is intended to mean, though, that I vouche
for the *diffs*, not the tree.

If I've changed five files, I should be signing a statement of:

	1) my belief about the identity of the immediate ancestor tree
	2) a robust summary of my changes, sufficient to recreate my
	   new tree given a faithful copy of the ancestor

That's a short enough amount of data that a human can really review it
and thus it makes the signatures much more meaningful.

Probably doesn't matter much other than in cases where a mainline
is undergoing massive batch-patching based mostly on a web of trust.

But in that case --- someone or something generates purported diffs of
a tree; someone or something else scans those diffs and decides they
look good ---- and then on this basis, something distinct from
directly using those diffs occurs.  The diffs were used to vette the
change; the signature asserts that a certain tree is a faithful result
of applying those diffs.  Nothing checks that second assertion -- it's
taken on faith.

-t

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/