RE: Making git history strictly time safe

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx]
Sent: Wed 5/16/2012 6:50 PM
To: Jones, Brian P CTR SPAWARSYSCEN-PACIFIC, 63600
Cc: git@xxxxxxxxxxxxxxx
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@xxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]