This bug was split from bug 333685. It is entirely possible that all 3 parties in a Git push are different: - author of a change - committer of a change (GPG signed by a dev, plus signed-off-by) - pusher of a change Ergo, on the server side, we need to log SSH identities during pushes. It might make sense to do it inside the update hook per bug #502060, as we want denials to be logged as well. This mainly comes down to just recording the Gitolite username from the environment.
Additionally, do we care about logging which SSH key of a user was used for the push?
I wonder if this is really necessary. I don't think there are many circumstances that you would need to find out who pushed a change. If you really needed it, I think you can find that already from wtmp. Actually, I'm not entirely sure this language actually makes sense. Git pushes can send multiple commits, but also tags, and also move branches backward (if force push is enabled on both ends).
(In reply to Alex Xu (Hello71) from comment #2) > I wonder if this is really necessary. See the discussion about potentially malicious users in pushes as part of the grsec investigation of git commit signing. > I don't think there are many circumstances that you would need to find out > who pushed a change. If you really needed it, I think you can find that > already from wtmp. The problem is that the wtmp entry does not have a direct correlation from an SSH login to what git refs were touched by the login. > Actually, I'm not entirely sure this language actually makes sense. Git > pushes can send multiple commits, but also tags, and also move branches > backward (if force push is enabled on both ends). - Force push will be disallowed. Read update.sample in the git source, that is the script we'll be basing our work on, as it already handles: - create (unannotated) tag - create (annotated) tag - delete tag - modify tag - commit to regular branch (including master) - create regular branch - delete regular branch - commit to tracking branch - create tracking branch - delete tracking branch
(In reply to Robin Johnson from comment #3) > (In reply to Alex Xu (Hello71) from comment #2) > > I wonder if this is really necessary. > See the discussion about potentially malicious users in pushes as part of > the grsec investigation of git commit signing. I'm not following that, would you happen to have a link? > > I don't think there are many circumstances that you would need to find out > > who pushed a change. If you really needed it, I think you can find that > > already from wtmp. > The problem is that the wtmp entry does not have a direct correlation from > an SSH login to what git refs were touched by the login. I know, but wouldn't the time be enough? > > Actually, I'm not entirely sure this language actually makes sense. Git > > pushes can send multiple commits, but also tags, and also move branches > > backward (if force push is enabled on both ends). > - Force push will be disallowed. > > Read update.sample in the git source, that is the script we'll be basing our > work on, as it already handles: > - create (unannotated) tag > - create (annotated) tag > - delete tag > - modify tag > - commit to regular branch (including master) > - create regular branch > - delete regular branch > - commit to tracking branch > - create tracking branch > - delete tracking branch This is in all (locally-init'd?) git repositories. :) Looks like it might be enough just to echo "$GL_USER: " "$@" > /var/log/whatev ... wait. TIL that gitolite already does logging. remote: GL_LOGFILE=/var/lib/gitolite/.gitolite/logs/gitolite-2014-02.log
(In reply to Alex Xu (Hello71) from comment #4) > > See the discussion about potentially malicious users in pushes as part of > > the grsec investigation of git commit signing. > > I'm not following that, would you happen to have a link? http://thread.gmane.org/gmane.linux.gentoo.scm-migration/104 That's part of the discussion, I don't have a link from the discussion on the grsec side however, sorry. > > > I don't think there are many circumstances that you would need to find out > > > who pushed a change. If you really needed it, I think you can find that > > > already from wtmp. > > The problem is that the wtmp entry does not have a direct correlation from > > an SSH login to what git refs were touched by the login. > I know, but wouldn't the time be enough? Why take the chance? Just log to syslog and be done with it. > > Read update.sample in the git source, that is the script we'll be basing our > > work on, as it already handles: .. > This is in all (locally-init'd?) git repositories. :) Anywhere that you choose to use that update.sample script, including remote sides. > Looks like it might be enough just to echo "$GL_USER: " "$@" > > /var/log/whatev For the update hook yes, for pre/post-recieve, you have to log stdin as well. > ... wait. > TIL that gitolite already does logging. > remote: GL_LOGFILE=/var/lib/gitolite/.gitolite/logs/gitolite-2014-02.log Ooh, that's come a long way since I last looked at it, it needs some slight modifications: - syslog destination instead of files - log gpg validation state - gentoo's /etc/logrotate.d/gitolite makes a HORRIBLE mess of that directory
(In reply to Robin Johnson from comment #5) > (In reply to Alex Xu (Hello71) from comment #4) > > > See the discussion about potentially malicious users in pushes as part of > > > the grsec investigation of git commit signing. > > > > I'm not following that, would you happen to have a link? > http://thread.gmane.org/gmane.linux.gentoo.scm-migration/104 > That's part of the discussion, I don't have a link from the discussion on > the grsec side however, sorry. > > > > The problem is that the wtmp entry does not have a direct correlation from > > > an SSH login to what git refs were touched by the login. > > I know, but wouldn't the time be enough? > Why take the chance? Just log to syslog and be done with it. I suppose so. > > > Read update.sample in the git source > > This is in all (locally-init'd?) git repositories. :) > Anywhere that you choose to use that update.sample script, including remote > sides. I meant that .git/hooks/update.sample exists for most repositories. > > Looks like it might be enough just to echo "$GL_USER: " "$@" > > > /var/log/whatev > For the update hook yes, for pre/post-recieve, you have to log stdin as well. > > > ... wait. > > TIL that gitolite already does logging. > > remote: GL_LOGFILE=/var/lib/gitolite/.gitolite/logs/gitolite-2014-02.log > Ooh, that's come a long way since I last looked at it, it needs some slight > modifications: > - syslog destination instead of files wouldn't that be too much for syslog? I don't know. to implement that, I think you would need to patch gitolite. > - log gpg validation state has to wait until we actually implement that ;) > - gentoo's /etc/logrotate.d/gitolite makes a HORRIBLE mess of that directory ah. well, that needs to be fixed. I don't use logrotate, so I don't seem to have that issue.
(In reply to Alex Xu (Hello71) from comment #6) > > - syslog destination instead of files > wouldn't that be too much for syslog? I don't know. git.overlays.g.o generates ~20kb of logs/day in the gitolite directory. The rest of Gentoo's systems generate ~1GB/day of logs. I think we can handle it ;-). > to implement that, I think you would need to patch gitolite. Looks like it, but shouldn't be too difficult. > > - log gpg validation state > has to wait until we actually implement that ;) Yes.
This would be in src/lib/Gitolite/Common.pm, sub gl_log, around line 265 (in stable).
Thought about using a git note for the successfull push, recording who did what?
(In reply to Brian Harring from comment #9) > Thought about using a git note for the successfull push, recording who did > what? I like this idea. It would be better if the notes UI didn't suck so much though. http://git-scm.com/blog/2010/08/25/notes.html (That gives me an idea, we could have two branches, master and stable, and the stable one being committed to by tinderboxen and pulled from by rsync. But I digress.) You need to fetch notes with: $ git fetch origin refs/notes/*:refs/notes/* Or configure them manually with: fetch = +refs/notes/*:refs/notes/* in .git/config. I suppose that wouldn't be a huge deal though. "If you want to see who pushed a commit, you need to set this thing up first. Or use cgit/gitweb."
I won't object to notes, but they would be in addition to syslog. We'll be sending the syslog output to other systems, so from the point of view of the server where the git repo is hosted, that log is guaranteed to be immutable.
https://groups.google.com/d/topic/gitolite/iUmnDKaHYXM/discussion http://gitolite.com/gitolite/dev-notes.html#appendix-4-v3.6.1-syslog
