O/H Karsten Wade έγραψε:
> On Sat, 2007-07-14 at 00:55 +0200, Jeroen van Meeuwen wrote:
>> Mike McGrath wrote:
>>> 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.
>
> The benefits of these new tools far outweigh the relatively slight
> risks. We really must step up and find a way to make it work.
>
> My vote is simple: we do the best we can, we spell out what the
> security is and the risks involved, and we put that in front of upstream
> projects. We ask them to agree (via email?) to the risk/reward balance
> we present. [...]
>
> Security risk assessment is never about, "No matter the cost, I will
> secure this until it is unbreakable." That guarantee comes from a pair
> of wire cutters used on the CAT(5) between the server and the switch.
> Great for security, bad for business. [...]
>
> Remember, a risk assessment has to balance the rewards.
>
> In this case, the rewards are ENORMOUS:
>
> * Anyone notice how translate.fedoraproject.org and transifex have just
> solved in six weeks many of the complaints people have about Launchpad
> and Rosetta?
>
> * Do we think upstream projects are going to want the ability to add an
> army of translators?
>
> Full disclosure of the security measures in place should be enough for
> upstream to decide if the rewards are worth the risk.
Karsten pretty much summarized all my thoughts on the whole idea of transifex.
Thanks mate. :)
I plan to start by directly using `~/.ssh/` and one key for all remote repos. If
it's not hard to do multiple keys (I think it isn't) via `.config`, then cool.
For starters, we can try it out with {cvs, hg, git}.fpo. And i18n.redhat.com if
the folks behind it want to be part of this.
This will give us a proof-of-concept implementation and will help us document
the procedure and understand what more we can do in the area of security and
usability. Then I'd be happily accepting any patches to add more layers of
security, like eg.:
* Adding SELinux to protect the keys
* Moving `.ssh` out of `~/`
* Creating a new program/daemon to handle the VCS transactions
And some more high-level controls that could bump the system's trust:
* Add editors (eg. lang maintainers) who only them could push the changes after
reviewing them
* Publish local repos to add the choice for a maintainer to pull the
translations instead for transifex to push them to the main repo
-d
--
Dimitris Glezos
Jabber ID: glezos@xxxxxxxxxx, GPG: 0xA5A04C3B
http://dimitris.glezos.com/
"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--
