0

I notice git do allow a user to commit using arbitary timestamp and author, so there are a few potential abuses that I could think of:

  • Situation 1 : if we are using git to generate activity logs, how can we make sure the timestamps are genuine ? people could commit with fake timestamps long ago, is there a way to verify?
  • Situation 2: in case other people commit and sabotage using my name as Author, is there a way to find out?
Jin
  • 17
  • 4
  • Think of this like artwork and forgeries. The answers are: 1: no. 2: no, but you can use *digital signatures* to sign either commits (this is extremely strict and rather brittle and I don't recommend it) or tags (this is much more usable and I recommend this method instead) to distinguish a genuine "Jin commit" from a forgery. – torek Jan 16 '22 at 11:25
  • On top of that, many tools register when things were pushed, that may give an indication of whether a date was manipulated. – jessehouwing Jan 16 '22 at 11:35
  • but even if it is pushed late, people can still argue these early commits are authentic and looks like there is no way to either verify or deny that.. : ( – Jin Jan 16 '22 at 11:52
  • https://stackoverflow.com/q/40512166/7976758 – phd Jan 16 '22 at 15:28
  • Depending on the number of repositories that are in use and the use pattern it is possible to establish a partial order on commits (e.g., it is not possible to merge something before it was committed; a commit after a merge is after the last commit of the merged-in branch, no matter what its timestamp says). If repositories communicate, say, on a daily basis there is a limit to undetectable timestamp forgery. – Peter - Reinstate Monica Jan 17 '22 at 17:04

2 Answers2

0

Situation 1+Situation 2:

For current and future commits you can create *-hook (I'll suggest precommit-), which check date and author of commit (from metadata) and compare with real date and (logged-in? authenticated?) user, reject if differ.

None for historical commits.

Situation 2:

Disallow not GPG-signed commits (signing is easy task, for any platform and OS)

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
  • The person doing the signing can still fudge their date. – jessehouwing Jan 16 '22 at 16:35
  • @jessehouwing - recommendation 2 **does not** replace recommendation 1 - different tasks assume difeent solutions – Lazy Badger Jan 16 '22 at 16:46
  • For 1, that only works when people turn that on locally and can be easily bypassed. A pre-receive hook may work better on the server, but that may prevent pushes of an existing repo to your server (creating a mirror, fork etc). – jessehouwing Jan 16 '22 at 16:51
  • @jessehouwing - mea culpa, I wrongly define type of hook. And yes, pre-receive hooks also have two sides - light and dark – Lazy Badger Jan 16 '22 at 17:03
0

Most git servers capture a "Push" action with the authenticated user who made the push and which commits were included in that. That is hard to fake, unless you have admin permissions on the server or access to the server's storage.

On the client when a commit is made the commit metadata is captured, but there is no guarantee the data is correct. Even when a user signs the commit, that signature can be made on the wrong date. GPG/PGP does not user an external time server authority to sign the time into the signature. It will prevent a user from changing commits (and their timing) made by other users though.

A solution that will satisfy all your requirements is to use SMIME signing against a timeserver. To do this each of your developers will need a code signing certificate and for them to configure it and a timeserver to authenticate both the person signing and the time of signing.

A pre-commit hook on the client can prevent accidental commit issues where the time is set incorrectly, but since the hook needs to be installed afte each clone (and can easily be removed) it provides little security against an adversary.

A pre-receive hook on the server can prevent accidental pushes to the central server that contain "old" commits, but may cause issues when you're importing repositories from another location (fork, mirror, etc).

Neither will prevent pushes where the local repo had changed times to within the safe time window of the server.

Your best approach here is to trust the "Pushes" metadata on the server for accurate timing of when data entered your organization and when old data was force pushed in. Possibly in combination with signing off commits with SMIME certificates and a timeserver.

See: https://www.glennwatson.net/posts/code-signing-github

GitHub setup

I am going to assume you want to use S/MIME signing for all your repositories. There are other options in the GitHub guide. We are going to generate a batch file to run smimesign due to a ongoing issue with timestamp authorities.

  1. Install S/MIME sign.
  2. Create a batch file that is in your path to smimesign. For windows the batch file sample (which you could name sign.cmd)
Copy to clipboard@echo off
smimesign.exe --timestamp-authority http://timestamp.digicert.com %*
  1. Tell git to use smimesign. From the command line run:
git config --global gpg.x509.program c:/path/to/sign.cmd
git config --global gpg.format x509
git config --global commit.gpgsign true
  1. Find the key you want to sign with. Run smimesign --list-keys and find the serial number of the key you wish to sign with. Copy the serial number of the key so you can paste it into the next command. Make sure you use the serial number not the ID.
  2. From the command line set the key to use git config --global user.signingkey a2dfa7e8c9c4d1616f1009c988bb70f

Now each time you commit it will ask you for a passcode that you set earlier.

See also: Sign git commit with x509 certificate in corporate environment

jessehouwing
  • 106,458
  • 22
  • 256
  • 341