Re: On undoing a forced push

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]