Re: Tracability in git commits

["Shawn O. Pearce" <spearce@spearce.org>]

Richard Purdie <rpurdie@rpsys.net> wrote:
> On Tue, 2008-04-29 at 14:34 -0700, Junio C Hamano wrote:
> > Richard Purdie <rpurdie@rpsys.net> writes:
> > 
> > > Assuming a shared server using something like gitosis each set of
> > > commits is made under a certain ssh ID and what I'd like is to be able
> > > to validate that against the commits so we could tell that commits A-D
> > > were made by ID Z.
>
> [...] I also understood the remote repository to be
> able to accept or reject commits/merges through its hooks?

Yes.  Look at contrib/hooks/update-paranoid for an example hook that
validates the committer name and email address of each new commit
matches with the real posix uid performing the push.  I use this
hook at day-job to validate pushes made by users over SSH through
a setuid git-receive-pack process.

The receive-pack program was patched to make it safer under setuid.
My patched version drops the setuid privs if the repository it
will write to or the hook(s) it will invoke are writable or owned
by anyone other than the effective uid.

But update-paranoid could be adapted to verify committer name/email
by some means other than just posix uid, such as by SSH public key.
 
> > And then the branch you granted the right to update its tip to that person
> > is updated, using that added part of the history.  The updates to the tip
> > will be recorded in reflog to record who updated the tip and when, [...]
> 
> This sounds like my answer, it's possible to trace who did what from the
> reflog. Which area of code is responsible for updating the reflog, is it
> in git itself or is it in the form of a hook? 

Pretty much all of git automatically updates the reflog when a
change takes place.  On the receiving side of a push event its
git-receive-pack that is handling the repository updates, and one
of the functions it calls is to add the event to the branch's reflog.

> I'm asking since if the repository is read/write for several users,
> faking the log is easy. If you use something like gitosis it runs under
> one user and faking is hard due to the restricted access. There is
> probably a need to feed extra information into whatever is making the
> log, or generate an additional log though due to the single user?

Right.  The reflog events are actually logged using the value of the
environment variables GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL.

So if you set these with whatever identity you want use prior
to invoking the server side git-receive-pack, you will get that
information in the reflog.  By default if these aren't set we use
the gecos information of the real uid.

Securing a repository means protecting limiting access to it.
You can reasonably protect a repository by making only a specific
user able to run git-receive-pack in that repository, but then
you need to arrange for individual users to execute as that user
over SSH.  The forced command feature associated with public keys
is often used for this, and its how gitosis does it.

My setuid hack to receive-pack will likely be retired at day-job
in the future.  We will either stop using git entirely, or we will
transfer over to forced commands in a common user authorized_keys,
like gitosis does.

-- 
Shawn.