Re: git push over http is very dangerous

[Christian <crich-ml@beronet.com>]

[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]

hi Junio,

today i got access to the machine with the corrupt git blobs, attached 
are the requested files, but there was no error, so i've not attached 
the output from stderr.

I hope this helps.


Christian



Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>   
>> On Mon, 16 Apr 2007, Christian wrote:
>>     
>>> We have moved from CVS to git in the beginning of last week, all went well
>>> until this weekend. This weekend one developer wanted to push some of his
>>> local modifications, unfortunately during the push his http connection seemed
>>> to have broken or so. Unfortunately git does not prove if the push went well.
>>> Therefore our repository was broken this morning.
>>>       
>> I have to agree: pushing over http really is dangerous.
>> ...
>>     
>
> Just for the record, I do not think anybody during that #git
> discussion actually proved that http-push was the culprit.  It
> is a very plausible working conjecture, though.
>
> I do not know if Nick is still using his own http-push (or if he
> is still using git for that matter), but just in case he may
> still be interested, I am cc'ing this message to him.
>
>   
>> I'd also love it if somebody were to actually look into making 
>> http-pushing a bit safer. It really needs somebody who cares about it, or 
>> it should likely just be disabled entirely (perhaps with a config option 
>> that you have to enable to get it - so that people *realize* that it's not 
>> maintained and not really supported).
>>     
>
> I think the fetch side does the right thing, more or less, by
> downloading to a temporary file and using move_temp_to_file()
> after validating the SHA-1 matches.  I haven't followed the push
> side but as we do not have a single line of code on the
> receiving end, I would not be surprised if there is no error
> checking beyond HTTP response code would give the pushing end.
>
> I would still love to see the corrupt loose object to see how it
> is broken.
>
> Christian, can you do this with the first (i.e. older) commit
> that is broken, and tar up these 7 files for the initial round
> of inspection?
>
> 	$ git cat-file commit $commit >commit-text 2>commit-error
>         $ git ls-tree ${commit} >toplevel-tree 2>toplevel-tree-error
>         $ git ls-tree -r -t ${commit} >whole-tree 2>whole-tree-error
> 	$ cp .git/objects/cd/1aac1a43cfdac07118240f75c0ba7662eb8140 corrupt
>
>
> -
> 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
>
>
>   


[-- Attachment #2: git-debug.tar.gz --]
[-- Type: application/gzip, Size: 1045 bytes --]