Here's the scenario...

I have a git repository on a server that may have been compromised. My development team say that they can trust the files in the directory that houses the git repository because all commits (diffs) and new files being added to the repository are checked and signed off by the repository 'owner' and any new files would show as new to the local version when a status or pull is made.

However I believe that if a person has compromised the server on which the git repository is housed, there must be some way to add a file to that repository and cover it up so that when a developer does their next pull, the new file doesn't show up in their git status. Is this the case?

  • (I don't really know but am making an educated guess). I suspect if you can create a new file with the same hash as an existing file you could replace the existing file with the new file and git would not be the wiser. This would be really difficult to achieve.
    – emory
    Jun 23, 2015 at 18:02
  • AFAIK the commit history log is not signed, so could you edit the log to make it look like that file was in the initial commit (or any arbitrary commit)? Jun 23, 2015 at 18:05
  • So I've not checked this personally to be certain, but it looks like git-rebase may be usuable to modify commit logs stackoverflow.com/a/4110978/537897 . also the identities that git stores aren't checked server side, anyone with access to the repository can call themselves anything they like when they commit (again AFAIK) Jun 23, 2015 at 18:13
  • @emory "I suspect if you can create a new file with the same hash" can two files have the same hash and have different contents at the same time?
    – Ulkoma
    Jun 23, 2015 at 18:40
  • @Ulkoma Yes, it's called a Collision Attack and it's a very common method for breaking hash functions. Jun 23, 2015 at 18:56

2 Answers 2


Your developers are correct in that any changes to the repository will be reflected by a new commit. Previous commits cannot be modified without all developers being notified of a serious conflict when updating from the remote repository.

That said, it would be trivial for an attacker to add a new commit to the repository that would automatically be downloaded and applied to developers' local repositories when pulling from the server. I find it extremely implausible that all commits to the repository are manually reviewed unless this is a very infrequently-used project. Even if they are reviewed, a motivated attacker could make an innocuous-looking change that has security implications. For example, in 2003, an unknown person added a commit to the Linux kernel that contained a root escalation vulnerability. This was back when Linux was using CVS, but the only real protection git has against this sort of attack is gpg-signed commits.

Unless you're using strong cryptographic signatures to protect your commits, there's no way to truly know whether or not a third party modified your repository without doing a full audit of all commits by the developer that supposedly authored them since the date of server compromise. This is the only way to truly ensure that an attacker didn't forge a commit by one of your developers.

It's up to you to determine whether or not the risk of the attacker having done this is worth the effort involved in trying to uncover it. If you're a small company making software that doesn't store, protect, or access sensitive data and this looks like a typical drive-by compromise to turn your server into a spam host, I probably wouldn't bother. If you process large quantities of money, I probably would.

Now would also be a good time to ensure that you aren't storing any credentials inside your repository. Things like database passwords, API keys to other services, TLS keys, and cryptographic secrets used for session cookie authentication should never be stored alongside your source code, and you should consider any that have been to be compromised and require rotation.

  • This was almost certainly my feeling. The check for authentication credentials has been made. I was interested whether commits could actually been 'hidden' though rather than showing up in developer pulls and not noticed/checked or ignored. Jun 23, 2015 at 20:16
  • 2
    No, the design of git does not allow that as a possibility. Jun 23, 2015 at 20:46

Building on what has been said, reading commit logs is everything however there are ways to trick the end user and having them download files that are not obvious to them.

One way is to add files to the git object database directly instead of the repo (so using git hash-object command instead of the normal git add). That way they don't appear when you type a list command, so it won't be obvious that they are pulled down.

$ echo 'version 1' > test.txt
$ git hash-object -w test.txt

Your database contains the new content:

$ find .git/objects -type f

I have seen projects use this method to hide secrets and credentials which is not secure and is simply security by obscurity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.