On Sat, Oct 29, 2016 at 12:08:31PM -0400, Matt McCutchen wrote: > Let's focus on the first scenario. There the user is just pulling and > pushing a master branch. Are you saying that each time the user pulls, > they need to look over all the commits they pulled before pushing them > back? I think that's unrealistic, for example, on a busy project with > centralized code review or if the user is publishing a project-specific > modified version of an upstream library. The natural user expectation > is that anything pulled from a public repository is public. No, I'm saying if you are running "git push foo master", then you should expect the contents of "master" to go to "foo". That _could_ have security implications if you come up with a sequence of events where secret things made it to "master". But it seems to me that "foo previously lied to you about what it has" is not the weak link in that chain. It is not thinking about what secret things are hitting the master that you are pushing, no matter how they got there. I agree there is a potential workflow (that you have laid out) where such lying can cause an innocent-looking sequence of events to disclose the secret commits. And again, I don't mind a note in the documentation mentioning that. I just have trouble believing it's a common one in practice. The reason I brought up the delta thing, even though it's a much harder attack to execute, is that it comes up in much more common workflows, like simply fetching from a private security-sensitive repo into your "main" public repo (which is an example you brought up, and something I know that I have personally done in the past for git.git). -Peff