git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git push over http is very dangerous

From
CChristian <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
>
>
>   
Previous: Linus TorvaldsNext: Junio C Hamano
Message 5 of 9 in “git push over http is very dangerous”
  1. ChristianApr 16, 2007
  2. Linus TorvaldsApr 16, 2007
  3. Junio C HamanoApr 16, 2007
  4. Linus TorvaldsApr 16, 2007
  5. ChristianApr 20, 2007
  6. Junio C HamanoApr 21, 2007
  7. ChristianApr 21, 2007
  8. Junio C HamanoApr 21, 2007
  9. ChristianApr 22, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.