Python, VCSs, ssh keys and Transifex

[Jeroen van Meeuwen]

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?
> 

Well, storing keys, key-pairs or their passwords no matter crypted or
salted, under the same user account that runs your webinterface
generally is a bad idea. (In fact, storing passwords in general is a bad
idea, no matter where they live).

Then again, you could have passwordless SSH private and public key
pairs, but you wouldn't want those usable by the account that has your
web interface running either.

A possible solution might be though, to have Transifex store the
submitted PO's in /some/path/transifex, and then have another user
account lift it's files and metadata, commit it to the pulled source
repository (signed with GPG), and then push it upstream (with SSH
priv/pub keys). Storing those passwords (plaintext or decryptable) would
make just as much sense to me as allowing empty passwords to use these
keys, but at least you prevent the webinterface from ever reaching those
keys or files.

I bet there's some thoughts on this ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip