Python, VCSs, ssh keys and Transifex

[Mike McGrath]

Dimitris Glezos wrote:
> 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.
>   

I'm surprised no one commented on this, I suspect they didn't read it 
:)  How did your paramiko search go?

    -Mike