Re: git push over http is very dangerous
- From
- Christian <crich-ml@beronet.com>
- Date
- Apr 20, 2007, 18:37 UTC
- Message-ID
- <4629086D.5010302@beronet.com>
- In-Reply-To
- <7vk5wcrt5m.fsf@assigned-by-dhcp.cox.net>
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:
Show 58 quoted lines
> 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
>
>
>