{"thread":{"id":"397","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","startedAt":"2005-04-29T21:45:50Z","lastAt":"2005-05-03T00:24:04Z","messageCount":3,"participants":["Horst von Brand","Tom Lord","Kevin Smith"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"2197","messageId":"200504292145.j3TLjoTC014157@laptop11.inf.utfsm.cl","threadId":"397","inReplyTo":"lord@emf.net","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-04-29T21:45:50Z","receivedAt":"2005-04-29T21:45:50Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Tom Lord said:\n> Think of it this way:\n> \n> (a) Joe, the mainline maintainer, gets a trusted message containing\n> a diff.\n> \n> (b) Joe reads the diff, it makes great sense, he wants to merge.\n> \n> (c) Joe downloads a tree. Supposedly that tree is the result of\n> applying this diff. The tree, not the diff, is used for\n> merging.\n> \n> You can see the logical whole there... now the practical one:\n> \n> \n> (d) Joe is repeating (a..c) at an unfathomably high rate.\n> At a low rate, he could be double-checking enough that\n> that the diff-vs-tree problem isn't that serious. But\n> at the rate he operates, exploits appear all along the\n> patch-flow pipeline because so much stuff goes unchecked.\n> \n> Joe may be scan the changes he's merged before committing but,\n> if his rate is high, that scan *must*, out of biological and\n> physical necessity, be shallow. Exploits can occur on the\n> submitter machine, in the communication channel, and on Joe's \n> machine. Social exploits can occur because of the separation\n> between a submitter saying \"this is what I'm doing\" vs. the reality\n> of what the submitter is doing.\n\nNow pray tell how Joe signing one, two, three, or none of the things he is\njuggling makes any difference here.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"2400","messageId":"200505022106.OAA28850@emf.net","threadId":"397","inReplyTo":"200504292145.j3TLjoTC014157@laptop11.inf.utfsm.cl","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Tom Lord","fromEmail":"lord@emf.net","sentAt":"2005-05-02T21:06:29Z","receivedAt":"2005-05-02T21:06:29Z","isPatch":false,"sender":{"key":"lord@emf.net","avatar":null},"body":"\n From: Horst von Brand \n\n Now pray tell how Joe signing one, two, three, or none of the things he is\n juggling makes any difference here.\n\nWe are talking about these signable things:\n\n\t1) Joe's assertions about the ancestry of his \n\t change.\n\n\t2) A full tree that Joe believes contains exactly\n\t his change, compared to the ancestry, in some\n\t well-defined way.\n\n\t3) A \"patch\" -- a statement of the well-defined \n\t change Joe is making.\n\n\nSigning (1) is mandatory if history-sensitive merges are to be\npossible.\n\nIf everything works perfectly, then signing (1) and (2) is\nmathematically equivalent to signing (1) and (3) and both are\nequivalent to signing (1), (2), and (3).\n\nThings don't work perfectly.\n\nA document containing (1) and (2) is, almost by definition, a \"human\nscale\" document. It reprepresents a real-world unit of human labor.\nIt summarizes the product of that labor in a human-readable, compact\nform. In most cases, a person could study a (1),(2) document in\ngreat detail, byte for byte, relying on very few software tools.\n\nBy contrast, a document containing (1) and (3), for a project as large\nas the kernel, can not be described as a \"human scale\" document: it\nrepresents the product of vast amounts of human labor -- exceeding a \nsingle human's capacity to fully comprehend. There are just too many\nbits there for a full tree to specifically represent a single human's \ndetailed *intensions* except indirectly.\n\nYou are countering, essentially, that programmers are afforded plenty\nof tools for comparing two trees. Therefore, as I understand you, any\nprogrammer with working tree-comparison tools can robustly commit a\n(1),(3) pair accurately. Similarly, any programmer can robustly\nreceive a (1),(3) pair and study it as if it were a (1),(2) pair -- so\nwhere's the problem?\n\nThe problem is in lot's of places but perhaps the clearest summary can\nbe presented as a communications problem. Supposing that work is done\nentirely with (1),(3) pairs:\n\n\n\tAlice and Bob both have a copy of the tree ORIG.\n\n\tAlice makes changes and now also has tree MOD_alice.\n\n Alice examines her changes locally. Her\n\tversion of the changes, summarized as a patch (aka changeset)\n is: CHANGES_alice.\n\n\tAlice signs the pair (a (1),(3) pair) and\n\tsends it to Bob.\n\n\tBob faithfully retrieves MOD_alice.\n\n\tBob compares Mod_alice to ORIG, using robust tools \n\the has at hand. The patch (aka changeset) which \n\tsummarizes the differences in his view is: CHANGES_bob.\n\n\nNothing in this scenario gives Bob a way to prove that CHANGES_bob ==\nCHANGES_alice. Bob can be as certain as we are content with that he\nwound up with the same _tree_ that Alice did, but he and Alice will\nhave to go out of their way if they want to check their communication\nin such a way that Bob can be confident Alice has checked that she\nsaid what she meant to say.\n\nMore bluntly, given just a (1),(3) pair, Bob is extending his vulnerability\nto include a reliance on Alice's patch-computing tools. If Alice were\nknown to be signing a (1),(2) pair which she had reviewed in detail,\nthen Bob's vulnerability stays at just his local patch-handling tools\nand his general trust of Alice.\n\nIn general, it's the potential specificity of a (1),(2) signature, rather\nthan a (1),(3), that makes (1),(2) signing the more robust idea (from\nthe robustness perspective).\n\n\n-t\n\n"},{"id":"2420","messageId":"4276C4A4.6020103@qualitycode.com","threadId":"397","inReplyTo":"200505022106.OAA28850@emf.net","subject":"Re: Mercurial 0.4b vs git patchbomb benchmark","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-05-03T00:24:04Z","receivedAt":"2005-05-03T00:24:04Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Tom Lord wrote:\n> More bluntly, given just a (1),(3) pair, Bob is extending his vulnerability\n> to include a reliance on Alice's patch-computing tools. If Alice were\n> known to be signing a (1),(2) pair which she had reviewed in detail,\n> then Bob's vulnerability stays at just his local patch-handling tools\n> and his general trust of Alice.\n\nI'm no expert, but it seems the opposite argument could be made as well.\nBy signing (1)(3), I am asserting that (3) is, in fact, what I intended\nthe end result to be. If I instead sign (1)(2), then it is possible that\nyour patching tools might end up producing something other than (3).\n\nPersonally, I still like the self-contained nature of signing (1)(2),\nbut I haven't yet heard a security argument in its favor.\n\nKevin\n"}]}