[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: On undoing a forced push
From:       Sitaram Chamarty <sitaramc () gmail ! com>
Date:       2015-06-09 14:50:29
Message-ID: 5576FD24.2040700 () gmail ! com
[Download RAW message or body]

On 06/09/2015 07:55 PM, Jeff King wrote:
> 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.

aah ok; I must have mis-remembered something.  Thanks!


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]