simplify code workflow for security issues

[chadwhitacre]

Currently our workflow for managing code changes for security issues calls for a separate repo for each issue, which derives from our previous GitHub-based security program (we wanted to be able to disclose security issues that were tracked in GitHub issues). Now that we've moved security issues to HackerOne, we should be able to move to a single private repo to handle all code changes related to security issues. Now, ideally, we'd have the private repo be a GitHub fork of our main public repo, with PRs permissioned appropriately. Stack Overflow suggests that we may be able to request this from GitHub support. I'm going to try. If that doesn't work out, we'll just maintain a non-forked second repo: we can still manage it as a manual fork (no PR niceness).

[chadwhitacre]

To: GitHub Support
Subject: fork in same org?

I would like to have a private fork of the gratipay.com repo in the same organization (Gratipay), to be used as part of our workflow for handling security issues. Is this something you can help me with? Thanks! :-)

P.S. As an open company, I'll need to at least summarize your responses publicly for the Gratipay community. That'll happen on this ticket.

[chadwhitacre]

I've set up a private repo: https://github.com/gratipay/security. The security team has write access.

[chadwhitacre]

I turned off the issue tracker (and the wiki) for the new security repo. We'll keep using HackerOne for security tickets.

[chadwhitacre]

I've mirrored the public gratipay.com repo into security.

[chadwhitacre]

Howto updated in dbd28d0.

[chadwhitacre]

No joy from GitHub support. The best they'll let us do is mirror. Okay!

[chadwhitacre]

I mean, we could make a second org, right? :)

[chadwhitacre]

Because really we should make the PR history public after deploying fixes for security issues. We're back to the same constraint with having all issues in a single private repo. What are PRs like from a private repo to a public one?

[chadwhitacre]

I'm reluctant to set up private testing on Travis, because our .travis.yml has notifications turned on for public IRC. Are we ready to turn that off?

[chadwhitacre]

Because really we should make the PR history public after deploying fixes for security issues.

For now let's try keeping all code review on HackerOne instead of on GitHub in the private repo. The commits will end up in the public repo, and the H1 conversation will also be disclosed. We lose the niceness of inline diff comments, etc., however.

[chadwhitacre]

Alright, that worked well enough. Howto updated.

Last thing on here is Travis.

[chadwhitacre]

Reopening to configure Travis for the security repo, now that public IRC notifications are off.

[chadwhitacre]

Access rights on Travis CI is based on the access rights on GitHub:

• Users that can access a repository on GitHub can see the build status and logs on Travis CI.
• Users that can push to a repository on GitHub can trigger, cancel and restart builds.
• Users that have admin access to a repository on GitHub can change enable/disable it on Travis CI and change its settings.

To keep the access rights up to date, we sync every user account approximately once every 24 hours with GitHub. You can use the “sync now” button on the profile page or travis sync --pro in the CLI to force a sync.

https://docs.travis-ci.com/user/travis-pro/#Who-has-access-to-the-builds%3F

[chadwhitacre]

Off and running!