# Re: Mercurial 0.4b vs git patchbomb benchmark 3 messages from 2005-04-29 to 2005-05-03. Participants: Horst von Brand, Tom Lord, Kevin Smith. Thread: https://gitlist.dev/t/397 ## Horst von Brand, 2005-04-29 21:45 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <200504292145.j3TLjoTC014157@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200504292145.j3TLjoTC014157%40laptop11.inf.utfsm.cl In-Reply-To: ``` Tom Lord said: > Think of it this way: > > (a) Joe, the mainline maintainer, gets a trusted message containing > a diff. > > (b) Joe reads the diff, it makes great sense, he wants to merge. > > (c) Joe downloads a tree. Supposedly that tree is the result of > applying this diff. The tree, not the diff, is used for > merging. > > You can see the logical whole there... now the practical one: > > > (d) Joe is repeating (a..c) at an unfathomably high rate. > At a low rate, he could be double-checking enough that > that the diff-vs-tree problem isn't that serious. But > at the rate he operates, exploits appear all along the > patch-flow pipeline because so much stuff goes unchecked. > > Joe may be scan the changes he's merged before committing but, > if his rate is high, that scan *must*, out of biological and > physical necessity, be shallow. Exploits can occur on the > submitter machine, in the communication channel, and on Joe's > machine. Social exploits can occur because of the separation > between a submitter saying "this is what I'm doing" vs. the reality > of what the submitter is doing. Now pray tell how Joe signing one, two, three, or none of the things he is juggling makes any difference here. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ``` ## Tom Lord, 2005-05-02 21:06 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <200505022106.OAA28850@emf.net> URL: https://gitlist.dev/e/200505022106.OAA28850%40emf.net In-Reply-To: <200504292145.j3TLjoTC014157@laptop11.inf.utfsm.cl> ``` From: Horst von Brand Now pray tell how Joe signing one, two, three, or none of the things he is juggling makes any difference here. We are talking about these signable things: 1) Joe's assertions about the ancestry of his change. 2) A full tree that Joe believes contains exactly his change, compared to the ancestry, in some well-defined way. 3) A "patch" -- a statement of the well-defined change Joe is making. Signing (1) is mandatory if history-sensitive merges are to be possible. If everything works perfectly, then signing (1) and (2) is mathematically equivalent to signing (1) and (3) and both are equivalent to signing (1), (2), and (3). Things don't work perfectly. A document containing (1) and (2) is, almost by definition, a "human scale" document. It reprepresents a real-world unit of human labor. It summarizes the product of that labor in a human-readable, compact form. In most cases, a person could study a (1),(2) document in great detail, byte for byte, relying on very few software tools. By contrast, a document containing (1) and (3), for a project as large as the kernel, can not be described as a "human scale" document: it represents the product of vast amounts of human labor -- exceeding a single human's capacity to fully comprehend. There are just too many bits there for a full tree to specifically represent a single human's detailed *intensions* except indirectly. You are countering, essentially, that programmers are afforded plenty of tools for comparing two trees. Therefore, as I understand you, any programmer with working tree-comparison tools can robustly commit a (1),(3) pair accurately. Similarly, any programmer can robustly receive a (1),(3) pair and study it as if it were a (1),(2) pair -- so where's the problem? The problem is in lot's of places but perhaps the clearest summary can be presented as a communications problem. Supposing that work is done entirely with (1),(3) pairs: Alice and Bob both have a copy of the tree ORIG. Alice makes changes and now also has tree MOD_alice. Alice examines her changes locally. Her version of the changes, summarized as a patch (aka changeset) is: CHANGES_alice. Alice signs the pair (a (1),(3) pair) and sends it to Bob. Bob faithfully retrieves MOD_alice. Bob compares Mod_alice to ORIG, using robust tools he has at hand. The patch (aka changeset) which summarizes the differences in his view is: CHANGES_bob. Nothing in this scenario gives Bob a way to prove that CHANGES_bob == CHANGES_alice. Bob can be as certain as we are content with that he wound up with the same _tree_ that Alice did, but he and Alice will have to go out of their way if they want to check their communication in such a way that Bob can be confident Alice has checked that she said what she meant to say. More bluntly, given just a (1),(3) pair, Bob is extending his vulnerability to include a reliance on Alice's patch-computing tools. If Alice were known to be signing a (1),(2) pair which she had reviewed in detail, then Bob's vulnerability stays at just his local patch-handling tools and his general trust of Alice. In general, it's the potential specificity of a (1),(2) signature, rather than a (1),(3), that makes (1),(2) signing the more robust idea (from the robustness perspective). -t ``` ## Kevin Smith, 2005-05-03 00:24 Subject: Re: Mercurial 0.4b vs git patchbomb benchmark Message-ID: <4276C4A4.6020103@qualitycode.com> URL: https://gitlist.dev/e/4276C4A4.6020103%40qualitycode.com In-Reply-To: <200505022106.OAA28850@emf.net> ``` Tom Lord wrote: > More bluntly, given just a (1),(3) pair, Bob is extending his vulnerability > to include a reliance on Alice's patch-computing tools. If Alice were > known to be signing a (1),(2) pair which she had reviewed in detail, > then Bob's vulnerability stays at just his local patch-handling tools > and his general trust of Alice. I'm no expert, but it seems the opposite argument could be made as well. By signing (1)(3), I am asserting that (3) is, in fact, what I intended the end result to be. If I instead sign (1)(2), then it is possible that your patching tools might end up producing something other than (3). Personally, I still like the self-contained nature of signing (1)(2), but I haven't yet heard a security argument in its favor. Kevin ```