Python, VCSs, ssh keys and Transifex

[Dimitris Glezos]

Hi all.

There is a darkish cloud of security uncertainty in my sky (and Fedora's!), so
it's better to discuss this as early as possible to avoid any late notices.

I'm working on a web app that will help translation submission by allowing
fedora translators (members of cvsl10n group) to commit translations to systems
they don't have direct access to. Think: hosted.fpo (svn/hg/git).

  https://hosted.fedoraproject.org/projects/transifex

The idea is that transifex will act as a proxy/mediator for translation commits.
A translator will login to the transifex instance running on a host like
`translate.fpo`, choose a module, a PO file to upload, and a destination file
and click "submit". The system will commit the file for him. Underneath this is
achieved by having the VCS admin create a user (eg. fedora-transifex) with a
dedicated SSH key, and give it write access to the specific modules accepting
translations. The transifex admin will then hook the repo and module up with the
system. Each commit will be done by the "fedora-transifex" user, and the actual
user's details (name, surname, email, fedora username) will be written in the
commit message and Changelog file. Transifex supports filaname filters, so even
if a module maintainer can't add ACLs to the repo, he can define them on the
transifex side; for example, .*/po/(LINGUAS|Changelog|.*po$).

To put things in perspective, if we do this *right*, then *any* remote VCS could
be hooked up. In the future, we could add a layer of "approval" before commits,
so that the language maintainer (which we probably trust more than a john doe
user with cvsl10n access) approves queued messages to be pushed. Or, we could
give the option to a dev (for DVCS) to pull instead of the webapp to push.


To the implementation details now, transifex will become the client to the
remote VCSs. Once the user clicks "submit PO", the webapp should commit (and
push). The security question is how do we handle SSH keys?

 - Where do we store them? Best place would be ~/.ssh/, because not all VCS
commands support SSH options to point to a different config file.

 - Right before running the checkout/pull and checkin/push commands, the
environment should be right so that the commands run by the webapp will succeed
over SSH. So an option the webapp (just like anyone) will have to "type" the
passphrase to unlock the key. Or, use ssh-agent. And probably SELinux. What's
the best approach with the minimum compromise risk?

 - Where are we going to actually store the keys and passphrase? On-disk or in
the DB? If we store them encrypted, where do we store the salt?

 - Do we need a different process running that handles these security requests?


Seeking the knowledge and experience of the wise, the humble developer comes to
you with seriously cold feet.

-d


-- 
Dimitris Glezos
Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--