search

mozilla / pontoon

Mozilla's Localization Platform
https://pontoon.mozilla.org
BSD 3-Clause "New" or "Revised" License
1.47k stars 528 forks source link

Sign L10n commits in git #2053

Open bugzilla-to-github opened 7 years ago

bugzilla-to-github commented 7 years ago

This issue was created automatically by a script.

Bug 1333108

Bug Reporter: @clouserw CC: @mathjazz

Git supports signing commits as another level of verification that they came from a specific person or group. The Test Pilot team has recently agreed to sign all their developer commits, but it would be nice to sign the Pontoon commits as well (and other projects would get the benefits as well).

I wrote a walk through at http://micropipes.com/blog//2016/08/31/signing-your-commits-on-github-with-a-gpg-key/

There isn't a hard deadline on this. We've been working with the security team to improve Test Pilot's security and this is the last thing on the list

bugzilla-to-github commented 7 years ago

Comment Author: @Pike

I have doubts here.

For one, we want to continue to commit localizations with the author being the localizer that actually worked on it. I haven't found any documentation on whether the key needs to be for the author or the committer. Yeah, I could just go through the whole process to try it out, or ...

which brings me to my more general concerns:

Conceptually, I expect that commits signed by pontoon automation would be poorly signed. All the secrets will be on some remote machine, and they'll be quite liberally shared among people that need to be able to set up the automation. So, the secrets won't be that much of a secret, and only as secure as the remote machine is.

Also, I'm concerned about the message that a signed commit could be mistaken with. Like Wil said in his initial comment, "we wan't to improve the security" ... . But a signed commit by pontoon doesn't really say that the commit won't cause harm to the site. There's always a chance that some string does something funky, and that some slip in the localizers work triggers a more or less fatal error in production.

For projects that would like to have rigor tracking of commits and the impact thereof, I think using an independent repository for pontoon to commit to, and to rigorously pick content from that repository for production, and lint the picked content as good as it can be for the production system is the right way forward.