Easier builds and deployments using Git over HTTPS and OAuth (opens in new tab)

The problem this solves is that you need credentials to clone a git repo from GitHub. That's easy: you can add an SSH "deploy" key to the repo.

BUT, dependency management tools (like bundler, pip and npm) allow you specify private repositories in your Gemfile/requirements.txt/package.json file. If you use a deploy key, you won't have access to those repositories and your CI wil fail. This isn't a problem you face as a developer, because you have an SSH key on your machine valid for all your GitHub repositories, this only affects your CI server.

So now a 3rd-party hosted CI server can use an Oauth token - something we already have - to download any repository you have access to.

There were already some ways of doing this - we could have added an SSH key for your user. But this is easier, and you don't get a notification saying "Circle has added an SSH key to your account", which panics people. This is also more convenient in a couple of other ways which I won't get into.

But there is one final problem, and it's a big one: your CI server adds this key to the machine before it checks code out. Since you can run arbitrary code in the CI server, you could possibly steal the OAuth key, and act as the user. Uh-oh! You can try and prevent this, but it's a bit tricky and error-prone.

So what Circle does instead is make you explicitly opt-in to a user key. If you need to access multiple repos, we'll detect it, and tell you how to explicitly opt-in. This means you'll also get a notification saying "Circle has added an SSH key to your account" which is good in our opinion. Then we don't use that key for public repos, and only use it when _you_ are the pusher (your teammates will use their own key). We're also making that key passworded, which you can't do with OAuth.

That still isn't good enough for everyone. Some people prefer to specify a user to run all their tests, and that user has restricted permissions using GitHub's team management tool. This is great, and something we explicitly support as the most secure.

So I think this is great if you're using your own CI server and trust everyone who can commit code to it. For 3rd-party CI servers like Circle, I feel what we're doing is safer. Feedback welcome.

Finally, I don't want this to appear negative. The problem that I raised above is one that GitHub is aware of, and one they are solving. I can't say how they're solving it, but I know that it does indeed solve it. I believe this is step one, and a great move in the right direction.

Looks like a great addition though, limiting scope is always a benefit