From: Linus Torvalds <[email protected]>
On Fri, 29 Apr 2005, Tom Lord wrote:
>
> 1) the ancestry of their modified tree
>
> 2) the complete contents of their modified tree
>
> 3) input data for a patching program (let's call it "PATCH")
> which, at the very least, satisfies the equation:
>
> MOD_TREE = PATCH (this_diff, ORIG_TREE)
>
> On the other hand, signing documents which represent a {(1),(3)} pair
> with robust accuracy is, in most cases, much much less expensive than
> signing {(1),(2)} pairs with robust accuracy.
Not so.
It may be less expensive in your world, but that's the whole point of git:
it's _not_ less expensive in the git world.
In the git world, 1 and 2 aren't even separate things. They go together.
And you just sign it. End of story. It's so cheap to sign that it's not
even funny.
The confusion here is that you are talking about computational complexity
while I am talking about complexity measured in hours of labor.
You are assuming that the programmer generating the signature blindly
trusts the tool to generate the signed document accurately. I am
saying that it should be tractable for human beings to read the documents
they are going to sign.
More importantly, signing 3 is meaningless. 3 only makes sense with a
known starting point. You should never sign a patch without also saying
what you're patching.
I advocated signing a {(1),(3)} pair, not simply (3).
And once you do that, 1+2 and 1+3 are _exactly_ the same thing.
I already spoke to that.
And since git always works on the 1+2 level, it would be inexcusably
stupid to sign anything but that. 3 doesn't even exist per se, although
it's obviously fully defined by 1+2.
So I don't see your point. You complain about git signing, but you
complain on grounds that do not _exist_ in git, and then your alternative
(1+3) which is senseless in a git world doesn't actually end up being
anything really different - just more expensive.
I'm not sure what to suggest other than go back and read more carefully.
-t
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
