7 messages, 7 authors, 2016-06-15 · open the first message on its own page
From: Tom Lord <hidden>
Date: 2016-06-15 22:41:55
> Call me a naive git, but seems to me the "git way" is a little > different. It's tree-based rather than diff-based, and doesn't involve > passing diffs around, right? Isn't that a significant part of what I said? Go back and read more carefully, is my suggestion. > Or am I missing something? Very much so. -t
From: Noel Maddy <hidden>
Date: 2016-06-15 22:41:55
On Fri, Apr 29, 2005 at 12:54:19PM -0700, Tom Lord wrote:
> Call me a naive git, but seems to me the "git way" is a little > different. It's tree-based rather than diff-based, and doesn't involve > passing diffs around, right? Isn't that a significant part of what I said? Go back and read more carefully, is my suggestion.
I'm trying to understand you. Please bear with me, and point out what I'm missing. Your example had Joe reviewing a signed diff, and then applying changes from a tree that "supposedly" had the diff applied correctly, but may have been corrupted. If the tree was not an accurate representation of applying the diff, then the changes Joe applied to his tree will be different than those that he reviewed. My example had Joe downloading a remote signed tree, reviewing the changes locally between his own trusted tree and the remote tree, and then applying them locally. Since the diffs are generated locally between the two trees, Joe is always reviewing the exact changes that will be applied to his tree. Doesn't this deal with the logical hole that you were pointing out in your example? Or am I seeing a different "logical hole" than you are? -- A man who fears nothing is a man who loves nothing. And if you love nothing, what joy is there in your life? -- King Arthur, "First Knight" +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Noel Maddy [off-list ref]
From: Andrew Timberlake-Newell <hidden>
Date: 2016-06-15 22:41:55
Tom Lord responded to Noel Maddy:
> Call me a naive git, but seems to me the "git way" is a little > different. It's tree-based rather than diff-based, and doesn't involve > passing diffs around, right? Isn't that a significant part of what I said? Go back and read more carefully, is my suggestion.
It looks to me like he did read carefully. There were two different ideas: TL) Passing tree & diff and trusting diff to create tree NM) Passing tree and generating diff versus local tree for review Maybe I'm reading them wrong, but that certainly looks like what each was expressing and they don't look like the same thing.
From: Kevin Smith <hidden>
Date: 2016-06-15 22:41:55
Tom Lord wrote:
> Call me a naive git, but seems to me the "git way" is a little > different. It's tree-based rather than diff-based, and doesn't involve > passing diffs around, right? Isn't that a significant part of what I said? Go back and read more carefully, is my suggestion. > Or am I missing something? Very much so.
So far, this is a frustrating conversation to watch. Here's my own interpretation, presented to help the participants understand whether or not their intended messages are getting through clearly. Originally, Tom seemed to claim that the problem was that git requires you to sign an entire tree, rather than a diff, even though the signer is only vouching for their diff. Linus responded by saying that a git signature of a tree would match that description, but signing a commit is different. I think he claimed that (by convention) signing a commit ONLY means you are signing the most recent change, which turned tree A into tree B. Tom then appeared to propose some specific attacks that could work against the git model. The precondition seems to be if the patch receiver does not exhaustively analyze each and every patch. The receiver trusts the contents based solely on who signed the commit object. One category of attacks were that a computer or communication channel was broken. It's not immediately clear to me how git's model contributes any weakness to these cases, compared to other signing strategies. The other category of attack mentioned was social, such as a signer creating a patch that claims to do one thing, but actually does another. Again, I don't see how git is weaker in this case than any other tool. Noel then pointed out that in practice, someone receiving a signed commit in git would view the commit comments and the diff, so the effect is similar to having the diff itself be signed. And that's where we are right now. So, from here, it looks like Tom needs to be more specific about which attacks might be more effective against git's signing strategy than against signed diffs. Kevin
From: Morgan Schweers <hidden>
Date: 2016-06-15 22:41:55
Greetings, On 4/29/05, Tom Lord [off-list ref] wrote:
> Call me a naive git, but seems to me the "git way" is a little > different. It's tree-based rather than diff-based, and doesn't involve > passing diffs around, right? Isn't that a significant part of what I said? Go back and read more carefully, is my suggestion. > Or am I missing something? Very much so.
It doesn't appear that he is. You appeared to predicate your argument on the 'auditor' believing a diff looks good, but getting a tree instead, that might not reflect the diff. Instead, in the git-world, the auditor actually gets a tree, and produces the diff themselves, and then decides whether the diff looks good enough to keep. The argument about the high velocity of git-transfers causing the inability to check doesn't appear to apply here, because the distributed development environment of Linux says that the 'gatekeepers' ARE in fact validating the changes from people in their area of expertise are good (or are relying on sub-gatekeepers), and then Linus is trusting them completely. This seems like the methodology that has been used up until now via bk previously. Git doesn't change that, and in fact supports that method of development. Your further suggestion that Linus could be replaced by a patch-manager, in that case, got a chuckle from me at least, but the more serious point is that Linus is necessary as the arbiter of who actually receives the absolute trust of a gatekeeper. He is, in effect, a meta-gatekeeper.
-t
In reading this conversation, it seems you're looking for a more absolute standard of trust than the kernel developers are working with. I believe this is an example of 'good enough' process being accepted, versus 'perfect' process. -- Morgan Schweers
From: David Lang <hidden>
Date: 2016-06-15 22:41:55
would it make sense for the network git protocol to be something along the lines of client contacts server and sends the tag you want to sync with (defaults to head) the local index file then the server can use the git tools locally to figure out what objects need to be sent to do the merge and only send those objects. no this isn't as efficiant as only sending diffs, but it avoids sending any objects that aren't needed (which would be sent if you just did a straight rsync) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
From: Daniel Barkalow <hidden>
Date: 2016-06-15 22:41:55
On Fri, 29 Apr 2005, David Lang wrote:
would it make sense for the network git protocol to be something along the lines of client contacts server and sends the tag you want to sync with (defaults to head) the local index file
Actually, you really want to have a bidirectional interaction, where the client first fetches the info to determine where to start, and then goes through the reachable space, asking for anything it doesn't already have. (In the long run, we want to keep track of some things we already have all of, or know we're missing, etc., so the receiver side doesn't have to look over its whole tree.) git already includes two versions of this protocol; the first runs against a static HTTP server, and the second uses ssh to get a socket. At some point, I'm going to enable these programs to read and write .git/refs/?/? to figure out what they're supposed to get. -Daniel *This .sig left intentionally blank*