# Making git history strictly time safe 5 messages from 2012-05-16 to 2012-05-18. Participants: Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600, Andrew Ardill, Sitaram Chamarty. Thread: https://gitlist.dev/t/30542 ## Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600, 2012-05-16 22:47 Subject: Making git history strictly time safe Message-ID: <2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil> URL: https://gitlist.dev/e/2EDEF5ABBE208442B7547C8D36B9D8840C4A03%40nawespscez09v.nadsuswe.nads.navy.mil ``` 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. I've found... http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite Which recommends setting... git config --system receive.denyNonFastforwards true git config --system receive.denyDeletes true ...Is this enough to guarantee time safe history? Notes: 1. Only certain process-central repositories would need time safe history. 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet). Brian P. Jones Senior Software Engineer Configuration Management ``` ## Andrew Ardill, 2012-05-17 01:50 Subject: Re: Making git history strictly time safe Message-ID: URL: https://gitlist.dev/e/CAH5451m33%2B4Y6sRzeji-Zvh2meN12ZxHKQMGRZ0Zwid8uGOyBw%40mail.gmail.com In-Reply-To: <2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil> ``` Brian, The first thing to know is that given a unique identifier for a commit, it's sha-1, it is guaranteed that the history of that commit will never change. Perhaps more accurately, the history is encoded with the commit contents as part of the sha-1, so it is as secure as sha-1. What can change are references to commits - branches, the HEAD reference, tags etc. Someone could take the contents of each commit, and use them to create a new history that is slightly altered, but this would be recorded as a different commit object, with a different sha-1. At this point they could point a reference, such as a branch, at this new commit object, and try to convince everyone that the history hasn't changed. Git will viciously warn everyone when they try to update this reference, requiring a force update to continue. My understanding is that the config options you show are enough to stop a remote user from updating a reference that changes history in the way I mentioned. If they did update a reference like this, the previous history would still exist, it would just not be referenced by the branch name etc. Regards, Andrew Ardill On 17 May 2012 08:47, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 wrote: > 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. > > I've found... > http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite > > Which recommends setting... > >  git config --system receive.denyNonFastforwards true >  git config --system receive.denyDeletes true > > ...Is this enough to guarantee time safe history? > > Notes: > 1. Only certain process-central repositories would need time safe history. > 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet). > > Brian P. Jones > Senior Software Engineer > Configuration Management > > -- > 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 ``` ## Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600, 2012-05-17 15:51 Subject: RE: Making git history strictly time safe Message-ID: <2EDEF5ABBE208442B7547C8D36B9D8840C4A04@nawespscez09v.nadsuswe.nads.navy.mil> URL: https://gitlist.dev/e/2EDEF5ABBE208442B7547C8D36B9D8840C4A04%40nawespscez09v.nadsuswe.nads.navy.mil In-Reply-To: ``` Andrew, 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? Brian ________________________________ From: Andrew Ardill [mailto:andrew.ardill@gmail.com] Sent: Wed 5/16/2012 6:50 PM To: Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 Cc: git@vger.kernel.org Subject: Re: Making git history strictly time safe Brian, The first thing to know is that given a unique identifier for a commit, it's sha-1, it is guaranteed that the history of that commit will never change. Perhaps more accurately, the history is encoded with the commit contents as part of the sha-1, so it is as secure as sha-1. What can change are references to commits - branches, the HEAD reference, tags etc. Someone could take the contents of each commit, and use them to create a new history that is slightly altered, but this would be recorded as a different commit object, with a different sha-1. At this point they could point a reference, such as a branch, at this new commit object, and try to convince everyone that the history hasn't changed. Git will viciously warn everyone when they try to update this reference, requiring a force update to continue. My understanding is that the config options you show are enough to stop a remote user from updating a reference that changes history in the way I mentioned. If they did update a reference like this, the previous history would still exist, it would just not be referenced by the branch name etc. Regards, Andrew Ardill On 17 May 2012 08:47, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 wrote: > 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. > > I've found... > http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite > > Which recommends setting... > > git config --system receive.denyNonFastforwards true > git config --system receive.denyDeletes true > > ...Is this enough to guarantee time safe history? > > Notes: > 1. Only certain process-central repositories would need time safe history. > 2. Developers can change their history provided it does not impact anyone else. I don't care about this case (yet). > > Brian P. Jones > Senior Software Engineer > Configuration Management > > -- > 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 ``` ## Andrew Ardill, 2012-05-18 01:49 Subject: Re: Making git history strictly time safe Message-ID: URL: https://gitlist.dev/e/CAH5451mwy51DjNM49ywDX5XHyLNMJSKk_NGiiQwydjgqyBzcNw%40mail.gmail.com In-Reply-To: <2EDEF5ABBE208442B7547C8D36B9D8840C4A04@nawespscez09v.nadsuswe.nads.navy.mil> ``` On 18 May 2012 01:51, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 wrote: > Andrew, > > 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? Exactly, as long as the tag wasn't moved for some reason (it is quite hard to move tags, but not /impossible/). If you wanted to be even more sure, you can write the sha-1 of the correct commit down on a piece of paper, and hide it in your wallet so no one is able to change it on you. Of course, if you have a local checkout of the repository there is nothing forcing you to accept changes someone else has made. This is what the flags on the server do, automatically rejecting changes that rewrite history. There is nothing stopping someone rewriting their own history on their local repository, all we can do is control what we have, which is the server and your local copy. In the end, as long as someone knows what the 'correct' reference is to the correct history, you won't lose anything. Regards, Andrew Ardill ``` ## Sitaram Chamarty, 2012-05-18 12:28 Subject: Re: Making git history strictly time safe Message-ID: URL: https://gitlist.dev/e/CAMK1S_g91K71hSo_N8Xz%2Bs3Y1snfGH0e2Z4hpVsviwGZ9P_S0g%40mail.gmail.com In-Reply-To: <2EDEF5ABBE208442B7547C8D36B9D8840C4A03@nawespscez09v.nadsuswe.nads.navy.mil> ``` On Thu, May 17, 2012 at 4:17 AM, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 wrote: > 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. > > I've found... > http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite > > Which recommends setting... > >  git config --system receive.denyNonFastforwards true >  git config --system receive.denyDeletes true > > ...Is this enough to guarantee time safe history? Yes. If you want something more fine-grained, you should consider using gitolite. For example you could say that only the master branch, and tags whose names start with "v" followed by a digit (followed by anything else) should be so protected, and that the other stuff can be rewound if someone wants to. http://sitaramc.github.com/gitolite/why.html shows you a couple of simple use cases for gitolite, although it does not explicitly address your situation. ```