-
Transifex and SSH keys
-
Returned from GUADEC, back to the development of transifex.
I’m at a point where most of the basic functionality works (if not all) for locally-hosted repositories. The
init.py
script creates 4 dummy “remote” repositories (cvs, svn, hg, git) in/var/tmp/
, and checkout/clones them “locally”, and you can commit/push to them through transifex.Transifex should be able to commit to remote repos, and the norm to do this is over SSH. So, the next step is to enable all operations happen over SSH, which basically means allowing modules to have repositories starting with
ssh://
or something, and switching it’s authtype (in the DB) from ‘None’ to ’ssh’ (I’ll think if this is needed at all).A lengthy email was sent to Fedora Infrastructure for advices on how to handle SSH keys in general. So the story is that we’ve got the TG app running on a server under a user (eg.
transifex@translate.fpo
), which will need to commit to many remote systems (eg.fedoral10n@hg.hosted.fpo
). There are a number of things to consider for the VCS checkout/commmit/push to take place:-
We need SSH keys (obvisouly).
-
Normally
ssh
stores keys in~/.ssh/
. If we’d like to override that and, say, store the keys in the database (because we are in a load-balanced environment where >1 filesystems are used) or in a different directory (eg. because we hate ~tildes since they remind us of the curly hair of the first girl that broke our heart), then we are starting to run into problems. For example, CVS doesn’t support passing arguments tossh
, which means we should create our own special ssh executable that actually callsssh
with the right options (u-g-l-y). -
The keys should apparently be encrypted (ie. created with
ssh-keygen -N'something'
). If so, who will “type” the passphrase to unlock them? -
If the web server gets compromised, can we make sure that it can’t access the SSH keys? What about the passphrase?
-
Maybe we ought to create a separate process/daemon that will actually do the VCS operations (and have access to the keys) and the webserver will instruct it to do whatever it wants. This way, the worse that could happen is to damage a remote VCS but at least the keys won’t be accessed (since they are owned by a different user than the one the webserver is running as).
-
Some upstreams might want to run the code that does the VCS operations themselves to make sure it’s OK. If so, we’d need to write an XMLRPC or something that enables either them to “pull” with a cron script from our service the operations (easier) or us to “push” requests for commit to their service (instant/live).
-
Things might get simpler if we rely on
ssh-agent
to handle the passphrase (either with or without the separate process/user). If the admin (a human) writes the passphrase
-