
Protecting Mozilla’s GitHub Repositories from Malicious Modification - jvehent
https://blog.mozilla.org/security/2018/09/11/protecting-mozillas-github-repositories-from-malicious-modification/
======
Boulth
> Production branches should be identified and configured:

> ...

> Require all commits to be GPG signed, using keys known in advance.

Is it possible to configure "all commits gpg signed" on Github? I haven't seen
this option.

Another interesting thing that Github lacks is signed git pushes (`gpg push
--signed`) that allows audit logging who moved which object to which ref.

~~~
masklinn
> Is it possible to configure "all commits gpg signed" on Github? I haven't
> seen this option.

Settings > Branches > [Add Rule] > <Apply Rule To> "*" > check "require signed
commits".

At least according to the help text:

> Commits pushed to matching branches must have verified signatures.

~~~
3pt14159
I've been signing my GPG commits for five years now.

The problem is that they don't allow GPG keys to be sunsetted. "Verified"
should be a property on the commit, not something computed. If I replace my
GPG key with something more secure, but I have no reason to believe my former
GPG key was stolen, I should be able to keep trusting the other commits.

~~~
Boulth
If you rotate your signing subkey then this would work as expected.

Rotating primary/master keys is a problem in OpenPGP in general (not just
Github).

~~~
3pt14159
Yeah.

I guess I've tended to shy away from subkeys because I figure losing the
primary is a function of time. Basically at some point a virus, or improperly
secured backup, is going to get my key.

Though I suppose the pro way of doing this would be to set up some kind of air
gaped PC, generate the subkey, then display it as a QR code or something.

~~~
Boulth
Yes, that's what I did but instead of copying the subkey via QR I put it on a
Yubikey. Actually it's more convenient that way as it's possible to use it on
any computer.

But from my perspective if you keep your master key super secure subkeys can
be your "operational keys" that are easily swapped when needed (I rotated my
subs when Yubico Infineon bug surfaced).

------
throw28363
It is a shame that a lot of critical projects (including compilers,
browsers...) still try to do things a la CVS/SVN (even if they use a DVCS).

Please, stop it. Do it the way the kernel does it. A hierarchy of maintainers
that reviews the work sent by others and a single person with commit access to
the main repository.

I am amazed that these smart people have not realizead yet that unrestricted
commit access is simpy a no-go, with or without signed commits/tags.

~~~
Leace
Github lowers barriers to entry for a lot of people and I guess Mozilla likes
that.

Compare creating a one line fix for a project on github and having a
discussion and review to sending a properly formatted patch to a mailing list
and following up on that.

I know that having properly configured mutt and git send-email eases most of
these pains but not everyone uses mutt and browsers have better consistency
between them than e-mail clients. You don't need to go through a guide to
configure your browser to send patches and participate in a review (vs
[https://nanxiao.me/en/configure-thunderbird-to-send-patch-
fr...](https://nanxiao.me/en/configure-thunderbird-to-send-patch-friendly/) ).

~~~
u801e
> Compare creating a one line fix for a project on github and having a
> discussion and review to sending a properly formatted patch to a mailing
> list and following up on that.

For the former:

* Create a Github account

* Fork the repository

* Set up the new git remote

* Push to that remote

* Open the pull request

* Wait for notifications via email

* Go back to the webpage and find the comment

* Modify the code, add, commit, push, and type a comment

* Repeat

Versus

* Configure git to use one's ISP's email server

* Run git format-patch

* Run git send-email

* Check email for replies

* Amend the commit, run git format-patch, and git send-email

* Reply to the maintainer email

* Repeat

To reply to emails, you can use any email client or even do that in the
browser. You only need to use the format-patch and send-email commands to send
patches.

~~~
lucideer
1\. Bias:

(a) You included setting up your local repo from the fork in the Github list
but it's implied in the 2nd list

(b) You included "Modify the code, add, commit, push, and type a comment" in
the first list: this is literally _how you use Git for normal development_. It
isn't an exclusive part of using Github

2\. Network effect:

(a) Creating a Github account is a one-time step: this will be omitted for any
platform with a large projectbase

(d) Most popular modern tooling/documentation/etc. are set up for the Github-
ish workflows and general user knowledge of `format-patch` and `send-email` as
commands is considerably more sparse.

~~~
u801e
> You included setting up your local repo from the fork in the Github list but
> it's implied in the 2nd list

Presumably one would have to clone the repo in order to make the modification
locally before forking. But whether or not one would fork the repo through the
GUI before cloning it depends on the person. I don't know which scenario is
more common. If it's the former, then they would have to handle setting up the
new remote for the fork before pushing up their code.

> You included "Modify the code, add, commit, push, and type a comment" in the
> first list

In the second list, I did state: "Amend the commit, run git format-patch, and
git send-email" which is essentially the same thing. The only difference is
that the first list implies that you make more commits (which is in line with
the expected pull request workflow on Github) while the second involves
amending the commit and resubmitting the patch (which is in line with the
expected workflow for email based review).

> general user knowledge of `format-patch` and `send-email` as commands is
> considerably more sparse.

Github explicitly tells you how to set up a remote when you create a new repo
and tells you how to clone a repo and has pages that tell you how to handle
pushing code up to the remote and how to set up your git config for your name
and email address. They don't assume that anyone has knowledge of those
commands (git push, git config --global --add user.name, git clone, git
branch, git remote add, etc). There's no reason why similar quick to read
documentation for git format-patch and git send-email couldn't also be
provided.

