On Tue, Jun 09, 2015 at 07:36:20PM +0530, Sitaram Chamarty wrote: > > This patch prints the latest SHA-1 before the forced push in full. He > > then can do > > > > git push <remote> +<old-sha1>:<ref> > > > > He does not even need to have the objects that <old-sha1> refers > > to. We could simply push an empty pack and the the remote will happily > > accept the force, assuming garbage collection has not happened. But > > that's another and a little more complex patch. > > If I am not mistaken, we actively prevent people from downloading an > unreferenced SHA (such as would happen if you overwrote refs that > contained sensitive information like passwords). > > Wouldn't allowing the kind of push you just described, require negating > that protection?
No, this has always worked. If you have write access to a repository, you can fetch anything from it with this trick. Even if we blocked this, there are other ways to leak information. For instance, I can push up objects that are "similar" to the target object, claim to have the target object, and then hope git will make a delta between my similar object and the target. Iterate on the "similar" object and you can eventually figure out what is in the target object. This is one of the reasons we do not share objects between public and private forks at GitHub. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
