2

Could a git history be falsified?

I'm thinking for instance about the following informations :

  • Commit date
  • Commit content
  • Identity of commiter

If yes :

  • Are there ways to authenticate a git repo's content or make it authenticatable?
  • How to know if a git history was modified?
vmonteco
  • 10,994
  • 12
  • 43
  • 73

3 Answers3

4

All the fields that you mentioned are part of the SHA-1 that is used to identify the commit. As such, it is impossible to change these fields without creating a new commit. And a new commit means, that no git implementation will accept the rewritten commit as a replacement for the original one, unless you force it to.

Generally, when you have a git commit ID, that is a cryptographic hash of all the development history up to that point, and all the authorship information that includes. Any change of that data will be detectable.

If you want extra security, you can sign-off commits with PGP keys using git commit -S.

cmaster - reinstate monica
  • 33,875
  • 7
  • 50
  • 100
  • What's the difference between PGP and GPG? – evolutionxbox Aug 14 '18 at 13:02
  • 1
    @evolutionxbox GPG is basically the GNU re-implementation of PGP. The crypto is compatible, but one piece of software is FOSS while the other is proprietary. GPG has been integrated into quite a bit of GNU/Linux software like `git`, but it's data format is still the one that PGP defined. – cmaster - reinstate monica Aug 14 '18 at 13:21
1

You can modify the details of a commit relatively easily: How to add a changed file to an older (not last) commit in Git

However, because the SHA-1 hash of each commit includes the hash of the parent commit, this changes the hashes of all following commits.

Are there ways to authenticate a git repo's content or make it authenticatable?

You can sign commits using GPG, but this only identifies the author. If the author has malicious intent, this brings us to your second question:

How to know if a git history was modified?

This depends on how you define "modified". As far as I know, there is no history on what master pointed to in the past, so you cannot easily distinguish a regular branch and a "modified" history. You might be able to check the rev-log for anything that looks odd.

mrks
  • 6,996
  • 26
  • 48
0

All version control systems (clearcase, subversion, CVS, git) history can be changed if you have access to the history. Git being distributed, you have a copy (i.e. fork) of the entire history. You can alter the history (see @mrks^1 answer) of your own fork only.

When you want to distribute back your copy, to push your changes to another fork, with --force you can thus overwrite the target history:

  • onlyif you have write access to the target remote fork
  • onlyif the remote branch is not set as readonly
  • any existing fork (except your current one) will notice the overwritten of the history and will ask you what to do (i.e. merge).

This is usually what is made in organizations to avoid other users to overwrite the history. And usually only the branch related to main production history path (e.g. branch = prod, production, master etc). This would be part of defining a workflow.

Many organizations^2 that have github mirrors have this setup, to make sure Github itself (intentionally or not) doesn't overwrites history, for example.

azbarcea
  • 1,977
  • 13
  • 17