RE: Making git history strictly time safe
- From
- Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil>
- Date
- May 17, 2012, 15:51 UTC
- Message-ID
- <2EDEF5ABBE208442B7547C8D36B9D8840C4A04@nawespscez09v.nadsuswe.nads.navy.mil>
- In-Reply-To
- <CAH5451m33+4Y6sRzeji-Zvh2meN12ZxHKQMGRZ0Zwid8uGOyBw@mail.gmail.com>
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:
Show 24 quoted lines
> 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