https://bugzilla.gnome.org/show_bug.cgi?id=599066 sysadmin | Git | unspecified
--- Comment #18 from Jeff Schroeder <[email protected]> 2010-10-29 21:14:54 UTC --- (In reply to comment #17) > (In reply to comment #8) > > Ok so here is the plan of attack... > > > > 1.) Setup a password-less ssh key for [email protected]. Make the > > private > > key readable by the gnomeweb _user_ only and not the group. l10n.gnome.org > > has > > fairly limited user access as is so the attack vector is lower than many > > other > > servers. > > Is damned lies really running as gnomeweb? Thought we pretty much gave up on > running web services under a non-apache user. We run django apps as user gnomeweb. mod_wsgi is very flexible and gives advantages to running things this way. The tomboy online webapp, snowy, runs as gnomeweb as well. > Basically if you have commit access to l10n.gnome.org you can make the account > do whatever you want, so I don't think locking down the key too hard has a > point. Readable-as-web-service-user seems about as good as we can easily do. Ok so the question is do we wand d-l to run the equivalent of git push directly to git.gnome.org? It does open things up a bit more, but in the worst possible case, someone reverts the commits and it is only language files. You seem to be of the opinion that it is ok to give users enough rope to hang themselves. I'm still working out the details of how things in gnome-land work :) > > 2.) Have create-auth[1] throw down a special ssh key[2] for the gnomeweb > > user > > including the host="boron.canonical.com,91.189.93.2" line when given the > > --gnomeweb-hack argument. This restricts ssh connections from that ssh key > > to > > only originate from l10n.gnome.org aka progress.gnome.org aka > > boron.canonical.com. > > > > The patch to do this is attached. Owen or someone else on the sysadmin team > > please review it to let me know if this is the right idea. create-auth is > > going > > to get a lot of love later on. Splinter is truncating the full length of the > > patch in my browser so look at it raw. > > See separate review. I agree with almost all of it, but can't respond indepth or do anything about it until later tomorrow or this weekend. That whole "real life" thing. > > 3.) On l10n.gnome.org, configure the git global user (and the d-l process > > that > > commits) to be "Damned-Lies Autocommit", and the global git client email to > > a > > mailinglist that emails all of the translators (if that list exists). This > > is > > for reply to go to the main l10n email list if someone wants to reply to an > > auto-checkin. > > I think [email protected] would be better. (Check that that's what we use for > bugzilla mail, etc.) Mail aliases imply accountability for responses. Also, I > would make the name something meaningful - Damned-Lies is an implementation > detail. That is all arbitrary and subject to change. > > 4.) Write a simple bourne shell git hook that runs these checks: > > a.) [ "$(/usr/bin/whoami)" = "gnomeweb" ] > > b.) [ "$(/usr/bin/id -u)" = "2184" ] > > c.) [ "$committer_name" = "Damned-Lies Autocommit" ] > > d.) [ "$committer_email" = "the email for the main l10n list" ] > > e.) If it works[2], logic similar to Claude's pseudocode would be > > perfect. > > > > I double-checked that whoami runs geteuid(2) (yay strace) so b isn't 100% > > necessary. The goal is max paranoia and gracefully die if anything is off. c > > and d are easy for anyone to circumvent with "git commit --author", but they > > are just an extra layer of sanity checking. e is to make sure that only > > translation files are being committed. > > Hmmm, not really a fan of belt-and-suspenders-and-duct-tape. Adding easily > circumventable checks just adds potential breakage without security. I'd do a > single check that we are confident in. /usr/bin/whoami = <translation user> > seems good enough to me. If you can subvert that, you can subvert the > operation > of the shell script and the system to the point where that single check > working > doesn't matter. History and smart people like Dan Walsh and Bruce Schneier have taught me security works best in layers. However, I'm still fairly new to how we handle things so this list will be shortened to a and e. > > 5.) Teach d-l how to commit translations to a local git repository and > > rebase > > ontop of changes (hello git.py). The sysadmin team will write a cronjob to > > periodically push commits to git.gnome.org as user gnomeweb. I'll address > > points 1-3 now and put this off to someone else until at very least after > > the > > Boston Summit. > > This part is all up to the damned lies maintainers - though that they already > had code. Transifex certainly does. Claude seems to be of the opinion d-l should do that. If you're ok with it, I'm ok with it. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the QA contact of the bug. You are watching the assignee of the bug. _______________________________________________ gnome-infrastructure mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-infrastructure
