Tracability in git commits

Tracability in git commits

[Richard Purdie]

Hi,

I've been wondering about whether its possible to provide some degree of
traceability of commits to a shared git repository. The potential
nightmare scenario is one developer making a commit pretending to be
someone else.

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 see a repository as a linear progression of commits and merges.

The simplest security check would check each commit/merge on this linear
progression and make sure it matches the ssh ID. The problem is where
someone merges in some external tree, someone else pulls it and pushes
it, only fast forward merges are made and the ssh 'ID' no longer matches
the ID of the merge which is in the linear path.

Someone mentioned some patches that are on the mailing list atm and the
idea of never allowing fast forward merges. Would the "never" policy of
fast forward merges solve this problem? Is there a simpler way to
address this or are there problems I'm not seeing?

Regards,

Richard

Re: Tracability in git commits

[Johannes Schindelin]

Hi,

On Tue, 29 Apr 2008, Richard Purdie wrote:

> I've been wondering about whether its possible to provide some degree of 
> traceability of commits to a shared git repository. The potential 
> nightmare scenario is one developer making a commit pretending to be 
> someone else.

You will probably not like my answer: if you do not trust your fellow 
developers, do not use a shared repository.  Use clones (such as Linux' 
many different repositories on kernel.org) instead.

Ciao,
Dscho

Re: Tracability in git commits

[Junio C Hamano]

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.

First of all, you need to learn the differences between making commits and
updating remote repositories.  Push does not create commits, it only
propagates a new part of commit DAG created elsewhere.

When you grant rights to a person to update the tip of a branch of a
repository, you are saying that you trust the person to advance the
history recorded on that branch in a way that is compatible with the goal
of the branch of your repository.

Whether you like it or not, git is a distributed system and git does not
care how that other person came up with the new part of the history.  The
person may find somebody else's work that is useful and apply patches to
his history (introducing commits whose authors are not himself), or merge
it (introducing commits whose committer are not himself), but you trust
that the person who does so uses good judgement, the same good judgement
he uses when making changes on his own.

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, which
would allow you to go back and point your finger at the person who
introduced problematic new history and at that point you really do not
care if the problem you have with the new history was due to faulty
commits the pusher made himself, was introduced by a merge the pusher did,
or was applied by the pusher from his mailbox.

Re: Tracability in git commits

[Richard Purdie]

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.
> 
> First of all, you need to learn the differences between making commits and
> updating remote repositories.  Push does not create commits, it only
> propagates a new part of commit DAG created elsewhere.

I understand that, yes. I also understood the remote repository to be
able to accept or reject commits/merges through its hooks?

> When you grant rights to a person to update the tip of a branch of a
> repository, you are saying that you trust the person to advance the
> history recorded on that branch in a way that is compatible with the goal
> of the branch of your repository.

but you can put a policy in place for that in the hooks if desired?

> Whether you like it or not, git is a distributed system and git does not
> care how that other person came up with the new part of the history.  The
> person may find somebody else's work that is useful and apply patches to
> his history (introducing commits whose authors are not himself), or merge
> it (introducing commits whose committer are not himself), but you trust
> that the person who does so uses good judgement, the same good judgement
> he uses when making changes on his own.

I appreciate this can happen and is often part of the normal workflow. I
have no objection to that, its more a question about whether it can be
controlled or at least logged...

> 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, which
> would allow you to go back and point your finger at the person who
> introduced problematic new history and at that point you really do not
> care if the problem you have with the new history was due to faulty
> commits the pusher made himself, was introduced by a merge the pusher did,
> or was applied by the pusher from his mailbox.

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? 

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?

Thanks,

Richard

Re: Tracability in git commits

[Shawn O. Pearce]

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.

Re: Tracability in git commits

[Ping Yin]

On Wed, Apr 30, 2008 at 5:34 AM, Junio C Hamano <gitster@pobox.com> wrote:


>  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, which
>  would allow you to go back and point your finger at the person who
>  introduced problematic new history

I don't find reflog for bare repository, or must i enable it manually?



-- 
Ping Yin

Re: Tracability in git commits

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

On Thu, May 01, 2008 at 01:33:53AM +0800, Ping Yin <pkufranky@gmail.com> wrote:
> I don't find reflog for bare repository, or must i enable it manually?

Right, reflog is disabled by default for bare repos.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Tracability in git commits

[Shawn O. Pearce]

Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, May 01, 2008 at 01:33:53AM +0800, Ping Yin <pkufranky@gmail.com> wrote:
> > I don't find reflog for bare repository, or must i enable it manually?
> 
> Right, reflog is disabled by default for bare repos.

`git config core.logAllRefUpdates true` right after you make the
repository solves that nicely.  I actually have a script that I use
to make a new bare central repo:

	#!/bin/sh
	git --git-dir="$1" init &&
	git --git-dir="$1" config core.logAllRefUpdates true ||
	exit

;-)

-- 
Shawn.

Re: Tracability in git commits

[Ping Yin]

On Thu, May 1, 2008 at 8:28 AM, Shawn O. Pearce <spearce@spearce.org> wrote:

>  `git config core.logAllRefUpdates true` right after you make the
>  repository solves that nicely.  I actually have a script that I use
>  to make a new bare central repo:
>
>         #!/bin/sh
>         git --git-dir="$1" init &&
>         git --git-dir="$1" config core.logAllRefUpdates true ||
>         exit

I wonder  why not make it the default behaviour. If someone push the
wrong commit to the bare repository (for example, with 'git push -f'),
there is no easy way to recover without reflog.

So as a solution, i would rather put this config to ~/.gitconfig




-- 
Ping Yin

Re: Tracability in git commits

[Jakub Narebski]

Richard Purdie <rpurdie@rpsys.net> writes:

> I've been wondering about whether its possible to provide some degree of
> traceability of commits to a shared git repository. The potential
> nightmare scenario is one developer making a commit pretending to be
> someone else.
[cut]

If you really need that, perhaps you would be better with using
Monotone, with its elaborate security and trust-related features?

IIRC we recommended Monotone to IPSec folks here...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: Tracability in git commits

[Richard Purdie]

On Wed, 2008-04-30 at 03:06 -0700, Jakub Narebski wrote:
> Richard Purdie <rpurdie@rpsys.net> writes:
> 
> > I've been wondering about whether its possible to provide some degree of
> > traceability of commits to a shared git repository. The potential
> > nightmare scenario is one developer making a commit pretending to be
> > someone else.
> [cut]
> 
> If you really need that, perhaps you would be better with using
> Monotone, with its elaborate security and trust-related features?
> 
> IIRC we recommended Monotone to IPSec folks here...

The project I'm thinking about is OpenEmbedded which used to use
bitkeeper and switched to monotone when bitkeeper went private only.

The issues with monotone are ones of poor performance, particularly with
the usage patterns we have, lack of good branching/merging capabilities,
lack of good web interfaces, high server load, some breakage issues and
a now general ill feeling amongst OE's developers.

Whilst monotone has improved tremendously from where it was, I'm not
sure certain features we need are going to appear in it within the
medium term which makes git look attractive.

When we switched to monotone we also lost our bitkeeper history which
I'd like to see us reunited with. I've been trying to make a sane
conversion of the bkcvs dump to git using git-cvsimport and the bkcvs
mode of cvsps but I'm having problems which I'll perhaps mention in
another email once I've had time to try and understand them properly.

Its by no means certain OE will switch but we want to setup a git trial
system and see exactly what we gain/lose. Evaluating the 'security'
consequences of a move is part of the equation. hg is another option
under consideration but not many of us have experience of it and we're
wary of choosing an SCM with a smallish userbase again amongst other
things.

Cheers,

Richard

Re: Tracability in git commits

[Martin Langhoff]

On Wed, Apr 30, 2008 at 10:32 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>  The project I'm thinking about is OpenEmbedded which used to use
>  bitkeeper and switched to monotone when bitkeeper went private only.

Richard,

you might be able to use a slightly tweaked workflow where you

 1 - Prepare a GPG-signed list of the commit hashes you are about to push
 2 - Push to an "incoming" repository that does weak or no validation
 3 - Push/publish your GPG-signed list of commit hashes
 4 - A script "pushes" commits from the "incoming" repo to a
"verified" repo after checking that they are backed by a GPG-signed
list. For ease of use, this can happen on the server ASAP, and it can
be validated independently by any party. Notably, it is probably a
good idea that it is validated shortly before a release is tagged.

This way, you keep the flexible/fast properties of git, but use the
SHA1 commit->tree>file relationship plus external wrapper scripts to
add auditing capabilities that are open and repeatable.

So all you need is

 - a trivial "push" wrapper that prepares the commits-to-push list and
automates the signing and publishing of the list
 - a trivial script to run the migration of verified commits

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Tracability in git commits

[Martin Langhoff]

On Thu, May 1, 2008 at 1:26 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
>   4 - A script "pushes" commits from the "incoming" repo to a
>  "verified" repo after checking that they are backed by a GPG-signed
>  list. For ease of use, this can happen on the server ASAP, and it can
>  be validated independently by any party. Notably, it is probably a
>  good idea that it is validated shortly before a release is tagged.
>
>  This way, you keep the flexible/fast properties of git

Note that with this, you *can* also keep the ability for someone to
push commits that they are not the author or committer for. This is
actually added flexibility - you can merge from a 3rd party tree, and
push it to the central repo, as long as you GPG-sign the list
including those commits.

I highlight "can" because the wrapper on the developer side and the
script on the server side can prevent this, or force extra steps in
such case.

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Tracability in git commits

[Junio C Hamano]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> On Thu, May 1, 2008 at 1:26 PM, Martin Langhoff
> <martin.langhoff@gmail.com> wrote:
>>   4 - A script "pushes" commits from the "incoming" repo to a
>>  "verified" repo after checking that they are backed by a GPG-signed
>>  list. For ease of use, this can happen on the server ASAP, and it can
>>  be validated independently by any party. Notably, it is probably a
>>  good idea that it is validated shortly before a release is tagged.
>>
>>  This way, you keep the flexible/fast properties of git
>
> Note that with this, you *can* also keep the ability for someone to
> push commits that they are not the author or committer for. This is
> actually added flexibility - you can merge from a 3rd party tree, and
> push it to the central repo, as long as you GPG-sign the list
> including those commits.
>
> I highlight "can" because the wrapper on the developer side and the
> script on the server side can prevent this, or force extra steps in
> such case.
>
> cheers,

I suspect that, with the "push to incoming, vet there and move to
verified" workflow, you do not need a special GPG-signed list.  You can
instead have the pusher sign the tip using the usual signed-tag mechanism,
which would sign the whole history leading to it, and have him push that
tag to the incoming together with the tip update.  You obviously do not
need nor want to move that signed tag to the final area.

Re: Tracability in git commits

[Martin Langhoff]

On Fri, May 2, 2008 at 7:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>  I suspect that, with the "push to incoming, vet there and move to
>  verified" workflow, you do not need a special GPG-signed list.  You can
>  instead have the pusher sign the tip using the usual signed-tag mechanism,
>  which would sign the whole history leading to it, and have him push that
>  tag to the incoming together with the tip update.  You obviously do not
>  need nor want to move that signed tag to the final area.

Yes. Though it makes a post-facto audit of who-pushed-which-commits
trickier - you'll have to correlate the reflogs in the server with the
signed tags. Having an explicit signature on a list of commits is a
bit more direct, easier to audit... IMHO anyway ;-)

cheers,



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff