Hi,
Summary:
I want to be able to log the information that the post-receive hook
receives, but I *also* want, along with that, the name of the pubkey
that was used in this particular "push".
Detail:
gitosis uses lines in ~git/.ssh/authorized_keys that use ssh's
"command=" feature. Specifically, the command is restricted to
"gitosis-serve username". Internally, gitosis uses this name to
decide if you're allowed to do what you're trying to do.
I'd like it to set an additional env var which will contain "username"
so that hooks etc can get that info and use it as they they see fit.
Q1: are there any downsides to doing this? I don't see any, you're
just creating and setting a new variable but...
Q2: if it's a good idea, can someone give me a hint about where to do
this? I'm useless at python but I'm willing to try.
Thanks,
Sitaram
From: Robin H. Johnson <hidden> Date: 2016-06-15 22:46:53
On Tue, Jun 02, 2009 at 09:32:40AM +0530, Sitaram Chamarty wrote:
I want to be able to log the information that the post-receive hook
receives, but I *also* want, along with that, the name of the pubkey
that was used in this particular "push".
I've got a partial patch that I never finished for using this with the
gitosis-gentoo fork that powers git.overlays.gentoo.org. It needs
re-implementation from scratch, but here's the design notes:
1. Use the username to open the file in keydir again.
2. At the top, look for RFC822 headers with a leading "# " as padding:
Examples from my own patch:
# Full-Name: "Robin H. Johnson (robbat2)" [off-list ref]
# cia-vc-username: robbat2
The headers are followed by a blank line then further text is free-form
and not parsed. Continuation lines are NOT supported.
3. The header field names are transformed to enviornoment variable names
as follows:
- y/[[:lower:]]/[[:upper:]]/g
- s/-/_/g
4. Export the environment variables, named per above, with the full
content of the rest of the line.
(We need to export the CIA.vc data, and also send off a commit mail).
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
On Tue, Jun 2, 2009 at 12:01 PM, Robin H. Johnson [off-list ref] wrote:
On Tue, Jun 02, 2009 at 09:32:40AM +0530, Sitaram Chamarty wrote:
quoted
I want to be able to log the information that the post-receive hook
receives, but I *also* want, along with that, the name of the pubkey
that was used in this particular "push".
I've got a partial patch that I never finished for using this with the
gitosis-gentoo fork that powers git.overlays.gentoo.org. It needs
re-implementation from scratch, but here's the design notes:
1. Use the username to open the file in keydir again.
This is the directory that contains all the *.pub files, so ok...
2. At the top, look for RFC822 headers with a leading "# " as padding:
Examples from my own patch:
# Full-Name: "Robin H. Johnson (robbat2)" [off-list ref]
# cia-vc-username: robbat2
Hmmm... is this a significantly different gitosis? The files in my
keydir mostly contain just one line (some have two, for people who
work from different machines), looking like this:
ssh-rsa [long series of base64 type characters]== some.one@company.com
The headers are followed by a blank line then further text is free-form
and not parsed. Continuation lines are NOT supported.
3. The header field names are transformed to enviornoment variable names
as follows:
- y/[[:lower:]]/[[:upper:]]/g
- s/-/_/g
4. Export the environment variables, named per above, with the full
content of the rest of the line.
(We need to export the CIA.vc data, and also send off a commit mail).
Nope, I'm completely lost. Perhaps I failed miserably in explaining
what I want... !
----------
I'm thinking along the lines of a simple change to this:
TEMPLATE=('command="gitosis-serve %(user)s",no-port-forwarding,'
+'no-X11-forwarding,no-agent-forwarding,no-pty %(key)s')
(in function generateAuthorizedKeys of gitosis/ssh.py) to generate an
additional ssh directive in the authorized_keys file:
environment="REMOTEUSER=%(user)s"
I haven't tested it yet, but I'm expecting that this will pass on the
name of the user (like "sitaram" in my case) as an env var so that I
can do whatever I want with it in the hooks.
Thanks,
Sitaram
This is useful if you want to implement access rights by branchname.
The update hook can check this variable and react accordingly.
Signed-off-by: Heiko Voigt <redacted>
---
On Tue, Jun 02, 2009 at 09:32:40AM +0530, Sitaram Chamarty wrote:
I'd like it to set an additional env var which will contain "username"
so that hooks etc can get that info and use it as they they see fit.
Here is a trivial patch. This is totally untested as I wanted to
implement something similar but never had the time to work more on it.
cheers Heiko
gitosis/serve.py | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Robin H. Johnson <hidden> Date: 2016-06-15 22:46:53
On Tue, Jun 02, 2009 at 06:49:22PM +0530, Sitaram Chamarty wrote:
quoted
2. At the top, look for RFC822 headers with a leading "# " as padding:
Examples from my own patch:
# Full-Name: "Robin H. Johnson (robbat2)" [off-list ref]
# cia-vc-username: robbat2
Hmmm... is this a significantly different gitosis?
The files in my keydir mostly contain just one line (some have two,
for people who work from different machines), looking like this:
ssh-rsa [long series of base64 type characters]== some.one@company.com
Comments ARE valid at the top of the files. Some of files have many
keys (users that keep keys unique to machines rather than use agents).
In the comments, we keep contact details for the user, as well as who
requested adding them, when, and for what purpose. The name of the file
is only for the ACL system. We had one potential conflict in naming
already, I got one of the users to rename to avoid having problems
elsewhere.
quoted
The headers are followed by a blank line then further text is free-form
and not parsed. Continuation lines are NOT supported.
3. The header field names are transformed to enviornoment variable names
as follows:
- y/[[:lower:]]/[[:upper:]]/g
- s/-/_/g
4. Export the environment variables, named per above, with the full
content of the rest of the line.
(We need to export the CIA.vc data, and also send off a commit mail).
Nope, I'm completely lost. Perhaps I failed miserably in explaining
what I want... !
No, it just seems that you aren't expecting the extra level of
indirection. Instead of explicitly exporting values via environment in
authorized_keys, OR in gitosis-serve (like the other patch), I teach
gitosis-serve how to find the keydir again, and extract pre-formatted
data.
Say I'm committing to gitosis.
The entry in the authorized keys is:
command="gitosis-serve robbat2",no-port-forwarding,no-X11-forwarding,...
When gitosis-serve runs, it goes and opens keydir/robbat2.pub.
The following headers are there:
# Full-Name: "Robin H. Johnson (robbat2)"
# Email: [off-list ref]
# cia-vc-username: robbat2
And the gitosis-serve mangles these per my instructions above, and does
os.putenv with them.
Then the following exists in the environment:
FULL_NAME='Robin H. Johnson (robbat2)'
EMAIL='robbat2@gentoo.org'
CIA_VC_USERNAME='robbat2'
Which are thus usable in the hooks.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
On Wed, Jun 3, 2009 at 1:51 AM, Robin H. Johnson [off-list ref] wrote:
No, it just seems that you aren't expecting the extra level of
indirection. Instead of explicitly exporting values via environment in
authorized_keys, OR in gitosis-serve (like the other patch), I teach
gitosis-serve how to find the keydir again, and extract pre-formatted
data.
Thanks for the detailed explanation. It makes sense, certainly.
However, I'll probably use/test the other patch :-) because that's
really all I need. In an open source project, it's necessary for
people to see other details (GPG FP even, as you showed), but in the
kind of single-digit-team-size internal projects I manage, just the
userid is quite enough.
Also, I'm not even going to send emails. All I want is to be able to
log each push to identify who did the push. That log may never be
looked at, but if is needed, it will have enough information to go on
with.
Of course, if the main gitosis gets your changes, that'll be great :-)
Thanks again,
Sitaram
On Tue, Jun 2, 2009 at 7:26 PM, Heiko Voigt [off-list ref] wrote:
This is useful if you want to implement access rights by branchname.
I see this as more fundamental than any specific purpose. Right now,
gitosis completely loses information on "who did this push", and this
fills that basic need.
And thanks for a patch that's even simpler than what I was *thinking*
of doing :-)
I will test it out today at work and report back but it should work; I
don't see why it wouldn't, unless somewhere else there's a
sanitisation of env vars going on for security.
Regards,
Sitaram
On Wed, Jun 3, 2009 at 6:34 AM, Sitaram Chamarty [off-list ref] wrote:
I will test it out today at work and report back but it should work; I
don't see why it wouldn't, unless somewhere else there's a
sanitisation of env vars going on for security.
On Wed, Jun 03, 2009 at 11:54:50AM +0530, Sitaram Chamarty wrote:
On Wed, Jun 3, 2009 at 6:34 AM, Sitaram Chamarty [off-list ref] wrote:
quoted
I will test it out today at work and report back but it should work; I
don't see why it wouldn't, unless somewhere else there's a
sanitisation of env vars going on for security.
works beautifully! Thanks again.
You are welcome. An interesting addition would be to propagate allowed
branchnames from gitosis.conf. That way you can implement write-
protected branches using an update hook.
Which enables better support for a maintainer based workflow for
centralized setups. Every developer would be allowed to push all branch
names he likes but the master branch is only writable by the maintainer.
A nice solution to steer this directly from gitosis.conf? I never got
around implementing it.
cheers Heiko
From: Robin H. Johnson <hidden> Date: 2016-06-15 22:46:53
On Wed, Jun 03, 2009 at 10:27:02PM +0200, Heiko Voigt wrote:
You are welcome. An interesting addition would be to propagate allowed
branchnames from gitosis.conf. That way you can implement write-
protected branches using an update hook.
...
A nice solution to steer this directly from gitosis.conf? I never got
around implementing it.
Has anybody implemented something like cvs_acls.pl (used by FreeBSD) for
Git?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:46:53
"Robin H. Johnson" [off-list ref] wrote:
On Wed, Jun 03, 2009 at 10:27:02PM +0200, Heiko Voigt wrote:
quoted
You are welcome. An interesting addition would be to propagate allowed
branchnames from gitosis.conf. That way you can implement write-
protected branches using an update hook.
...
quoted
A nice solution to steer this directly from gitosis.conf? I never got
around implementing it.
Has anybody implemented something like cvs_acls.pl (used by FreeBSD) for
Git?
contrib/hooks/update-paranoid ?
Perhaps the most flexible, and most paranoid, update hook available.
But it does require that the frontend set some sort of user identity.
I think it relies on UNIX uid, but its easy to hack to use an env
var instead from gitosis.
--
Shawn.