{"thread":{"id":"30542","subject":"Making git history strictly time safe","startedAt":"2012-05-16T22:47:11Z","lastAt":"2012-05-18T12:28:10Z","messageCount":5,"participants":["Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600","Andrew Ardill","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"191614","messageId":"2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil","threadId":"30542","inReplyTo":null,"subject":"Making git history strictly time safe","fromName":"Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600","fromEmail":"brian.p.jones4.ctr@navy.mil","sentAt":"2012-05-16T22:47:11Z","receivedAt":"2012-05-16T22:47:11Z","isPatch":false,"sender":{"key":"brian.p.jones4.ctr@navy.mil","avatar":null},"body":"I am working towards git adoption on a project. One of the concerns is the fear that git history is not guaranteed to be time safe. How can I configure a git repository so users cannot push or pull changes into it that change it's history? This includes keeping users who work directly in the repository from doing a rebase. \n \nI've found...\nhttp://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite\n \nWhich recommends setting...\n \n git config --system receive.denyNonFastforwards true\n git config --system receive.denyDeletes true\n \n...Is this enough to guarantee time safe history? \n \nNotes:\n1. Only certain process-central repositories would need time safe history. \n2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet).\n \nBrian P. Jones\nSenior Software Engineer\nConfiguration Management\n \n"},{"id":"191618","messageId":"CAH5451m33+4Y6sRzeji-Zvh2meN12ZxHKQMGRZ0Zwid8uGOyBw@mail.gmail.com","threadId":"30542","inReplyTo":"2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil","subject":"Re: Making git history strictly time safe","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-05-17T01:50:11Z","receivedAt":"2012-05-17T01:50:11Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"Brian,\n\nThe first thing to know is that given a unique identifier for a\ncommit, it's sha-1, it is guaranteed that the history of that commit\nwill never change. Perhaps more accurately, the history is encoded\nwith the commit contents as part of the sha-1, so it is as secure as\nsha-1.\n\nWhat can change are references to commits - branches, the HEAD\nreference, tags etc. Someone could take the contents of each commit,\nand use them to create a new history that is slightly altered, but\nthis would be recorded as a different commit object, with a different\nsha-1. At this point they could point a reference, such as a branch,\nat this new commit object, and try to convince everyone that the\nhistory hasn't changed. Git will viciously warn everyone when they try\nto update this reference, requiring a force update to continue.\n\nMy understanding is that the config options you show are enough to\nstop a remote user from updating a reference that changes history in\nthe way I mentioned. If they did update a reference like this, the\nprevious history would still exist, it would just not be referenced by\nthe branch name etc.\n\nRegards,\n\nAndrew Ardill\n\n\nOn 17 May 2012 08:47, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600\n wrote:\n> I am working towards git adoption on a project. One of the concerns is the fear that git history is not guaranteed to be time safe. How can I configure a git repository so users cannot push or pull changes into it that change it's history? This includes keeping users who work directly in the repository from doing a rebase.\n>\n> I've found...\n> http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite\n>\n> Which recommends setting...\n>\n>  git config --system receive.denyNonFastforwards true\n>  git config --system receive.denyDeletes true\n>\n> ...Is this enough to guarantee time safe history?\n>\n> Notes:\n> 1. Only certain process-central repositories would need time safe history.\n> 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet).\n>\n> Brian P. Jones\n> Senior Software Engineer\n> Configuration Management\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"},{"id":"191627","messageId":"2EDEF5ABBE208442B7547C8D36B9D8840C4A04@nawespscez09v.nadsuswe.nads.navy.mil","threadId":"30542","inReplyTo":"CAH5451m33+4Y6sRzeji-Zvh2meN12ZxHKQMGRZ0Zwid8uGOyBw@mail.gmail.com","subject":"RE: Making git history strictly time safe","fromName":"Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600","fromEmail":"brian.p.jones4.ctr@navy.mil","sentAt":"2012-05-17T15:51:35Z","receivedAt":"2012-05-17T15:51:35Z","isPatch":false,"sender":{"key":"brian.p.jones4.ctr@navy.mil","avatar":null},"body":"Andrew,\n \nIf I had a tag pointing to a commit that was so latter hidden could I easily return to the commit and say build it by referencing that tag without having to do any git magic?\n \nBrian\n \n________________________________\n\nFrom: Andrew Ardill [mailto:andrew.ardill@gmail.com]\nSent: Wed 5/16/2012 6:50 PM\nTo: Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600\nCc: git@vger.kernel.org\nSubject: Re: Making git history strictly time safe\n\n\n\nBrian,\n\nThe first thing to know is that given a unique identifier for a\ncommit, it's sha-1, it is guaranteed that the history of that commit\nwill never change. Perhaps more accurately, the history is encoded\nwith the commit contents as part of the sha-1, so it is as secure as\nsha-1.\n\nWhat can change are references to commits - branches, the HEAD\nreference, tags etc. Someone could take the contents of each commit,\nand use them to create a new history that is slightly altered, but\nthis would be recorded as a different commit object, with a different\nsha-1. At this point they could point a reference, such as a branch,\nat this new commit object, and try to convince everyone that the\nhistory hasn't changed. Git will viciously warn everyone when they try\nto update this reference, requiring a force update to continue.\n\nMy understanding is that the config options you show are enough to\nstop a remote user from updating a reference that changes history in\nthe way I mentioned. If they did update a reference like this, the\nprevious history would still exist, it would just not be referenced by\nthe branch name etc.\n\nRegards,\n\nAndrew Ardill\n\n\nOn 17 May 2012 08:47, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600\n wrote:\n> I am working towards git adoption on a project. One of the concerns is the fear that git history is not guaranteed to be time safe. How can I configure a git repository so users cannot push or pull changes into it that change it's history? This includes keeping users who work directly in the repository from doing a rebase.\n>\n> I've found...\n> http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite\n>\n> Which recommends setting...\n>\n> git config --system receive.denyNonFastforwards true\n> git config --system receive.denyDeletes true\n>\n> ...Is this enough to guarantee time safe history?\n>\n> Notes:\n> 1. Only certain process-central repositories would need time safe history.\n> 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet).\n>\n> Brian P. Jones\n> Senior Software Engineer\n> Configuration Management\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"},{"id":"191641","messageId":"CAH5451mwy51DjNM49ywDX5XHyLNMJSKk_NGiiQwydjgqyBzcNw@mail.gmail.com","threadId":"30542","inReplyTo":"2EDEF5ABBE208442B7547C8D36B9D8840C4A04@nawespscez09v.nadsuswe.nads.navy.mil","subject":"Re: Making git history strictly time safe","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-05-18T01:49:04Z","receivedAt":"2012-05-18T01:49:04Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 18 May 2012 01:51, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600\n wrote:\n> Andrew,\n>\n> If I had a tag pointing to a commit that was so latter hidden could I easily return to the commit and say build it by referencing that tag without having to do any git magic?\n\nExactly, as long as the tag wasn't moved for some reason (it is quite\nhard to move tags, but not /impossible/).\n\nIf you wanted to be even more sure, you can write the sha-1 of the\ncorrect commit down on a piece of paper, and hide it in your wallet so\nno one is able to change it on you.\n\nOf course, if you have a local checkout of the repository there is\nnothing forcing you to accept changes someone else has made. This is\nwhat the flags on the server do, automatically rejecting changes that\nrewrite history. There is nothing stopping someone rewriting their own\nhistory on their local repository, all we can do is control what we\nhave, which is the server and your local copy.\n\nIn the end, as long as someone knows what the 'correct' reference is\nto the correct history, you won't lose anything.\n\nRegards,\n\nAndrew Ardill\n"},{"id":"191658","messageId":"CAMK1S_g91K71hSo_N8Xz+s3Y1snfGH0e2Z4hpVsviwGZ9P_S0g@mail.gmail.com","threadId":"30542","inReplyTo":"2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil","subject":"Re: Making git history strictly time safe","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-05-18T12:28:10Z","receivedAt":"2012-05-18T12:28:10Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Thu, May 17, 2012 at 4:17 AM, Jones, Brian P CTR\nSPAWARSYSCEN-PACIFIC, 63600 wrote:\n> I am working towards git adoption on a project. One of the concerns is the fear that git history is not guaranteed to be time safe. How can I configure a git repository so users cannot push or pull changes into it that change it's history? This includes keeping users who work directly in the repository from doing a rebase.\n>\n> I've found...\n> http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite\n>\n> Which recommends setting...\n>\n>  git config --system receive.denyNonFastforwards true\n>  git config --system receive.denyDeletes true\n>\n> ...Is this enough to guarantee time safe history?\n\nYes.\n\nIf you want something more fine-grained, you should consider using\ngitolite. For example you could say that only the master branch, and\ntags whose names start with \"v\" followed by a digit (followed by\nanything else) should be so protected, and that the other stuff can be\nrewound if someone wants to.\n\nhttp://sitaramc.github.com/gitolite/why.html shows you a couple of\nsimple use cases for gitolite, although it does not explicitly address\nyour situation.\n"}]}