Making git history strictly time safe

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
 

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 <brian.p.jones4.ctr@navy.mil> 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?
 
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 <brian.p.jones4.ctr@navy.mil> wrote:

On 18 May 2012 01:51, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil> wrote:

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

On Thu, May 17, 2012 at 4:17 AM, Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil> wrote:

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.