CODEWITHSUNDEEP
git
user146043
user146043

Reputation:

Log of all Git operations

If you have a master (by convention) repo, and people use their own local repos, and someone abuses the "don't go back in time and rebase your changes instead of merging the branch in" or other (conventional) rules the git log isn't going to show you the full history of the remote repo - just the history as it pertains to the current state of the repo, right? Is there some way of seeing every last change that was made to the remote repo, to see who's not following the rules? I appreciate that the commits are gone and can't be gone back to (hence the problem) but just a text file containing the datas, SHAs etc would be handy. Does this exist? Can it be configured that way somehow?

To be clear; I'm interested in seeing everything which has been performed to the remote repo to track malicious or poorly trained usage of it.

Upvotes: 0

Views: 345

Answers (2)

Mark Adelsberger
Mark Adelsberger

Reputation: 45659

When you say a "master (by convention) repo", I assume you mean (1) there's a single "source of truth" repository for the project (which is conventionally called origin, not master); (2) users/devs clone the origin, work in their clones, and push changes to the origin.

In that usage, interactions with the origin boil down to very few - and in fact writes to the origin should always just be pushes. Things like rebase don't really occur at the origin; it is simply updated to see the result of those operations.

If you want any level of security or audit around the central repo, then this is the correct way to set it up. But, it means many of the things you're talking about, you can't directly "see". You won't know (and, honestly, shouldn't care) what commands were used to get a user's local repo into a particular state. You just know what's pushed - and any centrally-enforced rules need to be described in terms of what's pushed.

That means the useful tools are config options on origin, and the pre-receive hook (and possibly the update hook) on origin (unless you're in a hosted environment that provides a different security model).

One thing you can do is globally refuse to accept history rewrites. Then if someone rebases a branch after it's been pushed, origin simply won't take the push. (The user could still work on a branch, then rebase it before the first time they share it. There is nothing you can do about that, and really no good reason to care.) On the origin you'd set receive.denyNonFastForwards to true.

You can enforce pretty much whatever rule you want with a hook; if you can work out the necessary script. Maybe you want to enforce commit topology rules (e.g. "no non-merges in master" a la gitflow), or require signed commits (see below), or whatever.

If the rules are user-specific, or if you want to log potential violations instead of (or in addition to) blocking them, then authentication is a concern. Securing access to the repo - and authenticating who is accessing the repo - is not something git really addresses. There are several server environments for hosting git repos - like github, gitlab, TFS. Those types of server provide security options. You could also set your repo up so that the only way to reach it is through authenticated means (properly authenticated http, or ssl).

Accepting commits only if they're signed (or only if they're reachable from a signed tag) is also an option that tells you something about who did what, but maybe not what you want to know. (Just because I wrote and signed a commit, doesn't mean anything about who moved a ref to point to that commit and tried to push the result.)

If you can work out authentication, but can't script out detection of every rule - or maybe aren't sure what the rules need to be, but would know "bad behavior" when you see it - then simply logging the authenticated identity with the push's ref list would tell you probably everything you need to know to figure things out "after the fact".

Upvotes: 1

alexis
alexis

Reputation: 50190

Sounds like what you need is to set up an audit trail. It doesn't seem like there's built-in support for this in git, but you can keep a closer eye on the repo with the help of a couple of hooks.

Upvotes: 0

Related Questions