On undoing a forced push

> From a thread on Hacker News. It seems that if a user does not have
> access to the remote's reflog and accidentally forces a push to a ref,
> how does he recover it? In order to force push again to revert it
> back, he would need to know the remote's old SHA-1. Local reflog does
> not help because remote refs are not updated during a push.

> From a thread on Hacker News. It seems that if a user does not have
> access to the remote's reflog and accidentally forces a push to a ref,
> how does he recover it? In order to force push again to revert it
> back, he would need to know the remote's old SHA-1. Local reflog does
> not help because remote refs are not updated during a push.
> 
> 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.

> > 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?

> 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.

> On 06/09/2015 05:42 PM, Duy Nguyen wrote:
>> From a thread on Hacker News. It seems that if a user does not have
>> access to the remote's reflog and accidentally forces a push to a ref,
>> how does he recover it? In order to force push again to revert it
>> back, he would need to know the remote's old SHA-1. Local reflog does
>> not help because remote refs are not updated during a push.
>>
>> 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?

> Hi,
>
> On 2015-06-09 16:06, Sitaram Chamarty wrote:
>> On 06/09/2015 05:42 PM, Duy Nguyen wrote:
>>> From a thread on Hacker News. It seems that if a user does not have
>>> access to the remote's reflog and accidentally forces a push to a ref,
>>> how does he recover it? In order to force push again to revert it
>>> back, he would need to know the remote's old SHA-1. Local reflog does
>>> not help because remote refs are not updated during a push.
>>>
>>> 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?
>
> I believe that to be the case.
>
> Sorry to chime in so late in the discussion, but I think that the `--force-with-lease` option is what you are looking for. It allows you to force-push *but only* if the forced push would overwrite the ref we expect, i.e. (simplified, but you get the idea) `git push --force-with-lease <remote> <ref>` will *only* succeed if the remote's <ref> agrees with the local `refs/remotes/<remote>/<ref>`.

>
> If you use `--force-with-lease`, you simply cannot force-forget anything on the remote side that you cannot undo (because you have everything locally you need to undo it).
>
> Ciao,
> Johannes
> --
> 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

> diff --git a/transport.c b/transport.c
> index f080e93..6bd6a64 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -657,16 +657,17 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
>  			"[new branch]"),
>  			ref, ref->peer_ref, NULL, porcelain);
>  	else {
> -		char quickref[84];
> +		char quickref[104];

> On Tue, Jun 09, 2015 at 07:12:21PM +0700, Duy Nguyen wrote:
>> diff --git a/transport.c b/transport.c
>> index f080e93..6bd6a64 100644
>> --- a/transport.c
>> +++ b/transport.c
>> @@ -657,16 +657,17 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
>>                       "[new branch]"),
>>                       ref, ref->peer_ref, NULL, porcelain);
>>       else {
>> -             char quickref[84];
>> +             char quickref[104];
>
> You've increased this by 20, but you're adding 40 characters to the
> strcpy.  Are you sure that's enough?
>
> Also, you might consider writing this in terms of GIT_SHA1_HEXSZ, as it
> will be more obvious that this depends on that value.  If you don't now,
> I will later.

> On Tue, Jun 9, 2015 at 10:00 PM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > You've increased this by 20, but you're adding 40 characters to the
> > strcpy.  Are you sure that's enough?
> >
> > Also, you might consider writing this in terms of GIT_SHA1_HEXSZ, as it
> > will be more obvious that this depends on that value.  If you don't now,
> > I will later.
> 
> It's a demonstration patch and I didn't pay much attention. I think
> converting this quickref to strbuf may be better though, when you
> convert this file to object_id.