Python, VCSs, ssh keys and Transifex

[Jeroen van Meeuwen]

Mike McGrath wrote:
> Karsten Wade wrote:
>> On Wed, 2007-07-11 at 21:30 +0200, Jeroen van Meeuwen wrote:
>>
>>  
>>> 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.
>>>     
>>
>> Seems like an idea to pursue.  If httpd is the user doing the TurboGears
>> part, then have a transifexd that does the actual commits.  That
>> separation of the Web interface plus a good SELinux policy might be
>> enough.  How to trigger it?  Or let it run as a full-time daemon?
>>
>> The risk, folks, is that we get compromised and someone cracks an
>> upstream SCM through our servers.  Just think about that.  Enough to
>> turn a warm beer cold.
>>   
> 
> This is my worry too.  It's almost enough to make me not want to do it
> for non Fedora projects but thats just bad.  I'm hoping someone here has
> a good, clever way to solve this issue.
> 
>    -Mike
> 

So do I. A great deal of security would be achieved by having just a
small number of people actually know the GPG and RSA passwords, and have
them manually trigger the full commit/push. Then again, that requires
human interaction and isn't fully automated.

I'm thinking of a way where the user's credentials could be used to
trigger the signed commit and push without needing the GPG/RSA password
for the user transifex, but I'm not sure if it's even remotely possible
to like 'share' these keys and authorize different users to use them,
without (again) compromising the security principle of these tokens.

Kind regards,

Jeroen van Meeuwen
-kanarip