Richard Purdie <rpurdie@xxxxxxxxx> wrote: > On Tue, 2008-04-29 at 14:34 -0700, Junio C Hamano wrote: > > Richard Purdie <rpurdie@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
