Re: git push over http is very dangerous

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Attachment: git-debug.tar.gz
Description: application/gzip


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]