7 ms·

Protecting Mozilla’s GitHub Repositories from Malicious Modification

152 points by jvehent 8y ago

Boulth 8y ago
> 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 8y ago
  > 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.
  - Boulth 8y ago
    Thank you!
  - 3pt14159 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
        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).
        mattigames 8y ago
        Air-gaped PC could be any old smartphone you (or some friend) have lying around and set it on airplane mode then use it to generate keys as QR images (if you are truly paranoid then root it and delete the wifi/bluetooth drivers or use a home-made faraday cage)
- ElBarto 8y ago
  Proposed code changes should in any case be reviewed, tested, then committed by someone with the right to do so (which should be a restricted right). This is what really prevents malicious code changes.
  - Leace 8y ago
    Signed git pushes give you an opportunity to check if they really were "committed by someone with the right to do so". Without git push --signed you have to basically trust Github (which may be fine for most people's needs).
    - ElBarto 8y ago
      I don't know how github works but I would hope that there are users-based restrictions. "you have to basically trust Github" And that's why entrusting a third party with managing something as critical as your source code is unwise.
      - wongarsu 8y ago
        >And that's why entrusting a third party with managing something as critical as your source code is unwise. Yes, but signing your code strongly reduces the need for trust. If every commit is signed, and every checkout and clone checks that commits are signed by one of the trusted parties, Github has no chance to insert or modify code.
        Leace 8y ago
        > (...) Github has no chance to insert or modify code. Yes, exactly! The only slim window is refs. All-signed-commits still does not protect against someone pushing signed commit from branch "testing" to branch "master". But `git push --signed` [0] makes it possible to have an audit log of all ref modifications. [0]: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
        ElBarto 8y ago
throw28363 8y ago
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 8y ago
  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-friendly/ https://nanxiao.me/en/configure-thunderbird-to-send-patch-fr... ).
  - jopsen 8y ago
    It's also a balance... Most experimental researy projects don't need high security or high code quality. They just need to prove viability, etc..
  - u801e 8y ago
    > 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.
deleted 8y ago
[deleted]

152 points by jvehent 8y ago

> 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 8y ago
> 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.
- Boulth 8y ago
  Thank you!
- 3pt14159 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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).
      - mattigames 8y ago
        Air-gaped PC could be any old smartphone you (or some friend) have lying around and set it on airplane mode then use it to generate keys as QR images (if you are truly paranoid then root it and delete the wifi/bluetooth drivers or use a home-made faraday cage)
ElBarto 8y ago
Proposed code changes should in any case be reviewed, tested, then committed by someone with the right to do so (which should be a restricted right). This is what really prevents malicious code changes.
- Leace 8y ago
  Signed git pushes give you an opportunity to check if they really were "committed by someone with the right to do so". Without git push --signed you have to basically trust Github (which may be fine for most people's needs).
  - ElBarto 8y ago
    I don't know how github works but I would hope that there are users-based restrictions. "you have to basically trust Github" And that's why entrusting a third party with managing something as critical as your source code is unwise.
    - wongarsu 8y ago
      >And that's why entrusting a third party with managing something as critical as your source code is unwise. Yes, but signing your code strongly reduces the need for trust. If every commit is signed, and every checkout and clone checks that commits are signed by one of the trusted parties, Github has no chance to insert or modify code.
      - Leace 8y ago
        > (...) Github has no chance to insert or modify code. Yes, exactly! The only slim window is refs. All-signed-commits still does not protect against someone pushing signed commit from branch "testing" to branch "master". But `git push --signed` [0] makes it possible to have an audit log of all ref modifications. [0]: https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04 https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
      - ElBarto 8y ago

throw28363 8y ago

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 8y ago
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-friendly/ https://nanxiao.me/en/configure-thunderbird-to-send-patch-fr... ).
- jopsen 8y ago
  It's also a balance... Most experimental researy projects don't need high security or high code quality. They just need to prove viability, etc..
- u801e 8y ago
  > 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.

deleted 8y ago

[deleted]