Easier builds and deployments using Git over HTTPS and OAuth

https://github.com/blog/1270-easier-builds-and-deployments-using-git-over-https-and-oauth

by nigma • 14 years ago

41 11 14 years ago

github.com

amccloud• 14 years ago

Should be "Go forth and pull"

netherland• 14 years ago

You're right. Updated.

sitharus• 14 years ago

That doesn't look like OAuth to me, it looks like application level passwords.

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

pbiggar4• 14 years ago

Let me explain one big use case. I'm from CircleCi (hosted continuous integration - https://circleci.com) and this is really to help people like us out.

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.

daave• 14 years ago

Off-topic, but I saw your comment and I've been looking for a good CI solution that integrates with Github, and this was my first introduction to CircleCi.

I find it really off-putting that it's not possible to find out what your pricing plans are without signing up (and signing up requires giving you write access to my GitHub account).

mattdeboard2• 14 years ago

I went from knowing nothing about CI to setting up a full build job that deploys our various projects to multiple servers in a span of a few hours. What is the use case for hosted CI?

pbiggar4• 14 years ago

Hey Daave, I agree completely. We have a stupid technical problem where our inner and outer pages are separate apps, and we need to merge them to show the pricing on the outside. Stupid I know. We're fixing it.

zrail• 14 years ago

This seems like it'd be useful for using private forks of gems on Heroku, since you could just check that app key into your Gemfile. Right? Or am I misreading this.

pbiggar4• 14 years ago

You are exactly right.

Easier builds and deployments using Git over HTTPS and OAuth

Related Stories