{"thread":{"id":"7678","subject":"git push over http is very dangerous","startedAt":"2007-04-16T15:22:20Z","lastAt":"2007-04-22T07:21:37Z","messageCount":9,"participants":["Christian","Linus Torvalds","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39530","messageId":"462394AC.303@beronet.com","threadId":"7678","inReplyTo":null,"subject":"git push over http is very dangerous","fromName":"Christian","fromEmail":"crich-ml@beronet.com","sentAt":"2007-04-16T15:22:20Z","receivedAt":"2007-04-16T15:22:20Z","isPatch":false,"sender":{"key":"crich-ml@beronet.com","avatar":null},"body":"Hi Git developers,\n\nfirst of all thanks for the great toolkit :)\n\nWe are using git for the mISDN Open Source ISDN Stack (www.misdn.org / \ngit.misdn.org).  We are using webdav to push up data from users with \nwrite access. Readonly access is granted via the git daemon.\n\nWe have moved from CVS to git in the beginning of last week, all went \nwell until this weekend. This weekend one developer wanted to push some \nof his local modifications, unfortunately during the push his http \nconnection seemed to have broken or so. Unfortunately git does not prove \nif the push went well. Therefore our repository was broken this morning.\n\nWe found out that it was broken, because we could not do a pull or clone \nfrom the central repository anymore, but we got an error message.\n\nThen i did a \"git log\" which worked well. then i wanted to \"show\" the \nlast 2 commits, so i did: \"git show\":\n\nerror: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\n<crich1999> error: cd1aac1a43cfdac07118240f75c0ba7662eb8140: object \ncorrupt or missing\n\n\ni found that i could \"git show\" all commits, but only the last 2 \nproduced the above error message.\n\ngitster from IRC helped me out and showed me that i could do\n\ngit branch -f master master~2 \n\nto remove the 2 commits. i did that and all worked well again!\n\n\nI wonder if it would be possible to delay a central push until all data \nwas uploaded, then after the upload finished a checksum is transmitted, \nif the checksum is correct, the push can be done centrally..\n\n\ncheers,\n\nchristian\n"},{"id":"39567","messageId":"Pine.LNX.4.64.0704161212140.5473@woody.linux-foundation.org","threadId":"7678","inReplyTo":"462394AC.303@beronet.com","subject":"Re: git push over http is very dangerous","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-16T19:38:24Z","receivedAt":"2007-04-16T19:38:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 16 Apr 2007, Christian wrote:\n>\n> We have moved from CVS to git in the beginning of last week, all went well\n> until this weekend. This weekend one developer wanted to push some of his\n> local modifications, unfortunately during the push his http connection seemed\n> to have broken or so. Unfortunately git does not prove if the push went well.\n> Therefore our repository was broken this morning.\n\nI have to agree: pushing over http really is dangerous. It's not \n*supposed* to be (it tries to update the refs only after it has uploaded \nall objects), but it fundamentally cannot do all the validity tests that \nthe \"real\" git transfer processes do on the receiving side.\n\nAnd I think git-http-push is pretty fundamentally broken anyway. It \ndoesn't really seem to check for errors. So it doesn't do some of the \nchecks it *could* do.\n\nI would strongly suggest against http pushing (I'd suggest against pulling \ntoo, but at least you can't screw up too badly by just reading ;)\n\nI'd also love it if somebody were to actually look into making \nhttp-pushing a bit safer. It really needs somebody who cares about it, or \nit should likely just be disabled entirely (perhaps with a config option \nthat you have to enable to get it - so that people *realize* that it's not \nmaintained and not really supported).\n\n\t\tLinus\n"},{"id":"39569","messageId":"7vk5wcrt5m.fsf@assigned-by-dhcp.cox.net","threadId":"7678","inReplyTo":"Pine.LNX.4.64.0704161212140.5473@woody.linux-foundation.org","subject":"Re: git push over http is very dangerous","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-16T19:55:17Z","receivedAt":"2007-04-16T19:55:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Mon, 16 Apr 2007, Christian wrote:\n>>\n>> We have moved from CVS to git in the beginning of last week, all went well\n>> until this weekend. This weekend one developer wanted to push some of his\n>> local modifications, unfortunately during the push his http connection seemed\n>> to have broken or so. Unfortunately git does not prove if the push went well.\n>> Therefore our repository was broken this morning.\n>\n> I have to agree: pushing over http really is dangerous.\n> ...\n\nJust for the record, I do not think anybody during that #git\ndiscussion actually proved that http-push was the culprit.  It\nis a very plausible working conjecture, though.\n\nI do not know if Nick is still using his own http-push (or if he\nis still using git for that matter), but just in case he may\nstill be interested, I am cc'ing this message to him.\n\n> I'd also love it if somebody were to actually look into making \n> http-pushing a bit safer. It really needs somebody who cares about it, or \n> it should likely just be disabled entirely (perhaps with a config option \n> that you have to enable to get it - so that people *realize* that it's not \n> maintained and not really supported).\n\nI think the fetch side does the right thing, more or less, by\ndownloading to a temporary file and using move_temp_to_file()\nafter validating the SHA-1 matches.  I haven't followed the push\nside but as we do not have a single line of code on the\nreceiving end, I would not be surprised if there is no error\nchecking beyond HTTP response code would give the pushing end.\n\nI would still love to see the corrupt loose object to see how it\nis broken.\n\nChristian, can you do this with the first (i.e. older) commit\nthat is broken, and tar up these 7 files for the initial round\nof inspection?\n\n\t$ git cat-file commit $commit >commit-text 2>commit-error\n        $ git ls-tree ${commit} >toplevel-tree 2>toplevel-tree-error\n        $ git ls-tree -r -t ${commit} >whole-tree 2>whole-tree-error\n\t$ cp .git/objects/cd/1aac1a43cfdac07118240f75c0ba7662eb8140 corrupt\n"},{"id":"39572","messageId":"Pine.LNX.4.64.0704161303580.5473@woody.linux-foundation.org","threadId":"7678","inReplyTo":"7vk5wcrt5m.fsf@assigned-by-dhcp.cox.net","subject":"Re: git push over http is very dangerous","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-16T20:20:46Z","receivedAt":"2007-04-16T20:20:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 16 Apr 2007, Junio C Hamano wrote:\n> \n> Just for the record, I do not think anybody during that #git\n> discussion actually proved that http-push was the culprit.  It\n> is a very plausible working conjecture, though.\n\nI looked at http-push.c once more, and there is a very marked lack of any \nerror testing. It actually tries to be pretty careful, ie it seems that \nevery PUT request is always to a temp-file, and then it does a MOVE \nrequest after that, and things seem to properly abort on most errors, but \nthe actual data integrity is obviously impossible to check on the remote, \nand a quick grep showed that not all errors even set \"aborted\", which \nwould seem to imply that certain error conditions can happen without the \nhttp-push then aborting the ref update.\n\nFor example, if \"start_active_slot()\" fails, aborted isn't generally set. \nI don't know if that is ever a problem (it can only trigger with \nUSE_CURL_MULTI), but it's an example of what looks pretty fragile.\n\nSo we can fix up some of these kinds of things, but considering that we \ncan't really validate the end result on the remote, I'd still personally \nbe quite leery of pushing by http..\n\n> I think the fetch side does the right thing, more or less, by\n> downloading to a temporary file and using move_temp_to_file()\n> after validating the SHA-1 matches.\n\nYeah, on the pulling side we are simply much better off, because we can \nvalidate things after the operation has finished. On the pushing side, we \ncould obviously try to re-download the objects or something, but basically \nvalidation would literally have to involve doubling the network usage, and \neven then we might get screwed by some caching layer!\n\n\t\tLinus\n"},{"id":"39997","messageId":"4629086D.5010302@beronet.com","threadId":"7678","inReplyTo":"7vk5wcrt5m.fsf@assigned-by-dhcp.cox.net","subject":"Re: git push over http is very dangerous","fromName":"Christian","fromEmail":"crich-ml@beronet.com","sentAt":"2007-04-20T18:37:33Z","receivedAt":"2007-04-20T18:37:33Z","isPatch":false,"sender":{"key":"crich-ml@beronet.com","avatar":null},"body":"hi Junio,\n\ntoday i got access to the machine with the corrupt git blobs, attached \nare the requested files, but there was no error, so i've not attached \nthe output from stderr.\n\nI hope this helps.\n\n\nChristian\n\n\n\nJunio C Hamano wrote:\n> Linus Torvalds <torvalds@linux-foundation.org> writes:\n>\n>   \n>> On Mon, 16 Apr 2007, Christian wrote:\n>>     \n>>> We have moved from CVS to git in the beginning of last week, all went well\n>>> until this weekend. This weekend one developer wanted to push some of his\n>>> local modifications, unfortunately during the push his http connection seemed\n>>> to have broken or so. Unfortunately git does not prove if the push went well.\n>>> Therefore our repository was broken this morning.\n>>>       \n>> I have to agree: pushing over http really is dangerous.\n>> ...\n>>     \n>\n> Just for the record, I do not think anybody during that #git\n> discussion actually proved that http-push was the culprit.  It\n> is a very plausible working conjecture, though.\n>\n> I do not know if Nick is still using his own http-push (or if he\n> is still using git for that matter), but just in case he may\n> still be interested, I am cc'ing this message to him.\n>\n>   \n>> I'd also love it if somebody were to actually look into making \n>> http-pushing a bit safer. It really needs somebody who cares about it, or \n>> it should likely just be disabled entirely (perhaps with a config option \n>> that you have to enable to get it - so that people *realize* that it's not \n>> maintained and not really supported).\n>>     \n>\n> I think the fetch side does the right thing, more or less, by\n> downloading to a temporary file and using move_temp_to_file()\n> after validating the SHA-1 matches.  I haven't followed the push\n> side but as we do not have a single line of code on the\n> receiving end, I would not be surprised if there is no error\n> checking beyond HTTP response code would give the pushing end.\n>\n> I would still love to see the corrupt loose object to see how it\n> is broken.\n>\n> Christian, can you do this with the first (i.e. older) commit\n> that is broken, and tar up these 7 files for the initial round\n> of inspection?\n>\n> \t$ git cat-file commit $commit >commit-text 2>commit-error\n>         $ git ls-tree ${commit} >toplevel-tree 2>toplevel-tree-error\n>         $ git ls-tree -r -t ${commit} >whole-tree 2>whole-tree-error\n> \t$ cp .git/objects/cd/1aac1a43cfdac07118240f75c0ba7662eb8140 corrupt\n>\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n>\n>   \n\n"},{"id":"40018","messageId":"7vfy6uwncc.fsf@assigned-by-dhcp.cox.net","threadId":"7678","inReplyTo":"462394AC.303@beronet.com","subject":"Re: git push over http is very dangerous","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-21T01:03:15Z","receivedAt":"2007-04-21T01:03:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian <crich-ml@beronet.com> writes:\n\n> We found out that it was broken, because we could not do a pull or\n> clone from the central repository anymore, but we got an error message.\n>\n> Then i did a \"git log\" which worked well. then i wanted to \"show\" the\n> last 2 commits, so i did: \"git show\":\n>\n> error: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\n> <crich1999> error: cd1aac1a43cfdac07118240f75c0ba7662eb8140: object\n> corrupt or missing\n\nThanks.  I extracted that \"corrupt\" object, but all the archived\nversions of git I have at hand can read that tree just fine.\n\n  $ ~/git-snap-v1.0.0/bin/git ls-tree cd1aac\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n  $ ~/git-snap-v1.2.0/bin/git ls-tree cd1aac\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n  $ ~/git-snap-v1.3.0/bin/git ls-tree cd1aac\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n  $ ~/git-snap-v1.5.0/bin/git ls-tree cd1aac\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n  $ ~/git-snap-v1.5.1/bin/git ls-tree cd1aac\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n  $ git ls-tree cd1aac ;# this is 'next'\n  100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n  100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n  040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n\nI am starting to suspect that the loose object is actually Ok\nand you are suffering from something else (perhaps zlib).\n\nWe had a brief period that we had a bogusly strict error check\nafter calling zlib, which Linus fixed with 456cdf and ac54c2\n(these fixes are both in v1.5.1).  The breakage was 7efbff,\nwhich was post v1.5.0.3 breakage, but was never been part of any\nofficial release without the two fixes from Linus.\n\nHOWEVER (I mentioned the above paragraph to save people from\ngoing wild goose chase), this does not seem to be related to the\nbreakage.  I specifically built that revision and ls-tree from\nit reads the loose object just fine.\n\nThere is only one codepath that can emit this error message:\n\n> error: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\n\nso I am reasonably sure that you are running 7efbff or later\nversion, but now I am out of ideas.\n\nWhat version of git do you run?  And on what platform?\n"},{"id":"40058","messageId":"462A44B6.30404@beronet.com","threadId":"7678","inReplyTo":"7vfy6uwncc.fsf@assigned-by-dhcp.cox.net","subject":"Re: git push over http is very dangerous","fromName":"Christian","fromEmail":"crich-ml@beronet.com","sentAt":"2007-04-21T17:07:02Z","receivedAt":"2007-04-21T17:07:02Z","isPatch":false,"sender":{"key":"crich-ml@beronet.com","avatar":null},"body":"I've did that ls-tree thingy again additionally an ls-tree on a working \nblob:\n\n\nm24s12:/var/git/mISDN.git-backup2# git-ls-tree \ncd1aac1a43cfdac07118240f75c0ba7662eb8140\nerror: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\nfatal: not a tree object\nm24s12:/var/git/mISDN.git-backup2# ls objects/\nDisplay all 163 possibilities? (y or n)\nm24s12:/var/git/mISDN.git-backup2# ls objects/aa/\n537a125359b729699b3c011fbf9d71438de90d  \nd38d3dedd00107dc207190b9fa0b22f53888de\nm24s12:/var/git/mISDN.git-backup2# git-ls-tree \naa537a125359b729699b3c011fbf9d71438de90d 100644 blob \nf6998854080c88903e47d449affc891278184368    CHANGES\n100644 blob 0ac604f5c8c3b3a55fd0ce50944bb6f7f85850b3    Makefile\n100644 blob 7b90a319e218d962dc453c5a92b8ee11c6bb9b7d    Makefile.module\n100644 blob 56617b776024936b932601697ccfb548d891dadc    Makefile.standalone\n100644 blob c12695b2e27a3be524e8e2622f79abf638dd9fb1    Rules.make.ext\n100644 blob 1808a7786f86bf2ad9d15d2b7a921474bef00951    add.config\n040000 tree f422c9f8d89e2d5c8be05392522d79f064522d64    config\n040000 tree c875ea5c0cb3a5597df481f2999f9c6dc1691829    drivers\n040000 tree f1cb948bddd3a86d6a1981a903edb102bd8244cf    include\n100644 blob f11f1a276f4000b7bc703c40c3ad7a959ccf9146    km_mISDN.spec\n100755 blob 81c7103e38ef807e84880625ef484d50c4cc9cc3    std2kern\n100755 blob 07ba5902616674ddee962e89570c85f9e75fbd4b    stddiff\nm24s12:/var/git/mISDN.git-backup2# git --version\ngit version 1.5.1.1\n\nbut i had a 1.5.0.X version before, which emitted the same problem :(\n\nOn Friday i had access to the machine which created the corrupt object, \nthen we did a new push from that machine, which again corrupted our \ncentral repository, i found that it seemed not http - push related, \nbecause i could see the push worked well.\n\nDoing that was very unfortune, because we lost a lot of commits this \ntime :( I told that guy to get a new git version (he had 1.5.0.1 or so) \nand make a fresh clone of our repository.\n\nSo i'm pretty sure this is *not* a http push problem.\n\nInterestingly the git-ls-tree on the machine of that guy worked very \nwell, as it does on my local machine, but it does not work on our \ncentral repository.\n\nThe central machine is a  AMD Sempron, it runs Debian Sarge (3.1)  We've \ninstalled git from source, because sarge has it not in its archives.\n\nMaybe we did something wrong at building time ? or you're right and the \ndebian sarge zlib does not fit good to the current git versions ?\n\n\n\n\n\nJunio C Hamano wrote:\n> Christian <crich-ml@beronet.com> writes:\n>\n>   \n>> We found out that it was broken, because we could not do a pull or\n>> clone from the central repository anymore, but we got an error message.\n>>\n>> Then i did a \"git log\" which worked well. then i wanted to \"show\" the\n>> last 2 commits, so i did: \"git show\":\n>>\n>> error: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\n>> <crich1999> error: cd1aac1a43cfdac07118240f75c0ba7662eb8140: object\n>> corrupt or missing\n>>     \n>\n> Thanks.  I extracted that \"corrupt\" object, but all the archived\n> versions of git I have at hand can read that tree just fine.\n>\n>   $ ~/git-snap-v1.0.0/bin/git ls-tree cd1aac\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>   $ ~/git-snap-v1.2.0/bin/git ls-tree cd1aac\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>   $ ~/git-snap-v1.3.0/bin/git ls-tree cd1aac\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>   $ ~/git-snap-v1.5.0/bin/git ls-tree cd1aac\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>   $ ~/git-snap-v1.5.1/bin/git ls-tree cd1aac\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>   $ git ls-tree cd1aac ;# this is 'next'\n>   100644 blob 660424785bb8deda22ae5055fae1b16c466bc602\tKconfig.v2.6\n>   100644 blob 29553e41ee8d0941b1c119a3fdd4fcb9fa8cc44b\tMakefile.v2.6\n>   040000 tree 3ba0db3caae4263808c925a598d707aaf4f82d68\tmISDN\n>\n> I am starting to suspect that the loose object is actually Ok\n> and you are suffering from something else (perhaps zlib).\n>\n> We had a brief period that we had a bogusly strict error check\n> after calling zlib, which Linus fixed with 456cdf and ac54c2\n> (these fixes are both in v1.5.1).  The breakage was 7efbff,\n> which was post v1.5.0.3 breakage, but was never been part of any\n> official release without the two fixes from Linus.\n>\n> HOWEVER (I mentioned the above paragraph to save people from\n> going wild goose chase), this does not seem to be related to the\n> breakage.  I specifically built that revision and ls-tree from\n> it reads the loose object just fine.\n>\n> There is only one codepath that can emit this error message:\n>\n>   \n>> error: corrupt loose object 'cd1aac1a43cfdac07118240f75c0ba7662eb8140'\n>>     \n>\n> so I am reasonably sure that you are running 7efbff or later\n> version, but now I am out of ideas.\n>\n> What version of git do you run?  And on what platform?\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n>\n>   \n"},{"id":"40064","messageId":"7v4pn9vaye.fsf@assigned-by-dhcp.cox.net","threadId":"7678","inReplyTo":"462A44B6.30404@beronet.com","subject":"Re: git push over http is very dangerous","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-21T18:28:25Z","receivedAt":"2007-04-21T18:28:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian <crich-ml@beronet.com> writes:\n\n> The central machine is a  AMD Sempron, it runs Debian Sarge (3.1)\n> We've installed git from source, because sarge has it not in its\n> archives.\n>\n> Maybe we did something wrong at building time ? or you're right and\n> the debian sarge zlib does not fit good to the current git versions ?\n\nWhat I have been suspecting since I got that not-corrupted but\nreported to be corrupt tree is that the version running on your\n\"unable to fsck\" machine -- the one you use as the central\nmachine -- has a dud (or miscompiled) version of git, which\nsomehow reports corruption incorrectly on perfectly good\nobjects when it validates it before using them.\n\nAnd to that machine, push over http succeeds fine only because\npush over http is \"dangerous\" in that it does not \"validate\" the\npushed data on the receiving end like other codepaths do.\n\nIt would be interesting to find out what the breakage is on that\ncentral machine.  I think enough people run Sarge that it is\nunlikely it's zlib at fault, but the way git uses the zlib API,\nwhich was cleaned up in the current tree with the two fixes from\nLinus I mentioned earlier.\n"},{"id":"40101","messageId":"462B0D01.7000102@beronet.com","threadId":"7678","inReplyTo":"7v4pn9vaye.fsf@assigned-by-dhcp.cox.net","subject":"Re: git push over http is very dangerous","fromName":"Christian","fromEmail":"crich-ml@beronet.com","sentAt":"2007-04-22T07:21:37Z","receivedAt":"2007-04-22T07:21:37Z","isPatch":false,"sender":{"key":"crich-ml@beronet.com","avatar":null},"body":"Junio C Hamano wrote:\n> Christian <crich-ml@beronet.com> writes:\n>\n>   \n>> The central machine is a  AMD Sempron, it runs Debian Sarge (3.1)\n>> We've installed git from source, because sarge has it not in its\n>> archives.\n>>\n>> Maybe we did something wrong at building time ? or you're right and\n>> the debian sarge zlib does not fit good to the current git versions ?\n>>     \n>\n> What I have been suspecting since I got that not-corrupted but\n> reported to be corrupt tree is that the version running on your\n> \"unable to fsck\" machine -- the one you use as the central\n> machine -- has a dud (or miscompiled) version of git, which\n> somehow reports corruption incorrectly on perfectly good\n> objects when it validates it before using them.\n>   \nwell if you like i can give you an account to that machine offlist, i \ncould show you in a screen session where everything is.\n> And to that machine, push over http succeeds fine only because\n> push over http is \"dangerous\" in that it does not \"validate\" the\n> pushed data on the receiving end like other codepaths do.\n>\n> It would be interesting to find out what the breakage is on that\n> central machine.  I think enough people run Sarge that it is\n> unlikely it's zlib at fault, but the way git uses the zlib API,\n> which was cleaned up in the current tree with the two fixes from\n> Linus I mentioned earlier.\n>\n>\n>\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n>\n>   \n"}]}