News for hackers. Stuff that matters.
Re:Read-only deploy keys by pwenzel on Tuesday June 16, 2015 @04:26PM (#9728491)
Read only deploy keys are also a feature of Bitbucket: https://confluence.atlassian.com/display/BITBUCKET/Use+deplo...
[ Parent | on HN ]
Re:Read-only deploy keys by emmelaich on Tuesday June 16, 2015 @06:09PM (#9729015)
And in their enterprise equivalent Stash
[ Parent | on HN ]
Re:Read-only deploy keys by kkirsche on Tuesday June 16, 2015 @08:21PM (#9729441)
Sadly stash really isn't that great compared to GitHub or GitLab IMHO
[ Parent | on HN ]
Re:Read-only deploy keys by sytse on Wednesday June 17, 2015 @05:25AM (#9730747)
GitLab CEO here, thanks! And deploy keys in GitLab have always been read-only http://doc.gitlab.com/ce/ssh/README.html
[ Parent | on HN ]
Re:Read-only deploy keys by iancarroll on Tuesday June 16, 2015 @09:55PM (#9729717)
That's because any functionality not directly related to SCM is allocated to their other products, which integrate nicely.
[ Parent | on HN ]
Re:Read-only deploy keys by mianos on Tuesday June 16, 2015 @09:07PM (#9729601)
Now we wait another five years for the ability to share deploy keys across repositories. If you have more than one project in your CI deployable app (for example a couple of internal python libraries), you can't use the same deploy keys. Their suggestion, "don't use modules, package everything in one application or use a full key". Now deploy keys can be R/O (fantastic), this limitation is double annoying.
[ Parent | on HN ]
Re:Read-only deploy keys by ryan-c on Tuesday June 16, 2015 @10:02PM (#9729737)
workaround - add this to ~/.ssh/config

    Host *.github.com
    IdentitiesOnly yes
    IdentityFile ~/.ssh/%h_id_rsa
    HostKeyAlias github.com
    ProxyCommand nc github.com %p
use whatever.github.com as the hostname when cloning, and put the key in ~/.ssh/whatever.github.com_id_rsa
[ Parent | on HN ]
Re:Read-only deploy keys by sytse on Wednesday June 17, 2015 @05:25AM (#9730745)
GitLab CEO here, sharing deploy keys has been a feature for a long time in GitLab http://doc.gitlab.com/ce/ssh/README.html No need to wait five years :)
[ Parent | on HN ]
Re:Read-only deploy keys by philfreo on Tuesday June 16, 2015 @09:59PM (#9729729)
Rather than using Deploy Keys at all it seems completely better in almost every way to create a fake GitHub user and use its account's regular SSH key. You can, using Teams, give that user read-only access to whichever repo(s) it needs access to for deployment.
[ Parent | on HN ]
Re:Read-only deploy keys by baudehlo on Tuesday June 16, 2015 @10:04PM (#9729744)
Github calls these "machine users". But it's more annoying to manage than the deploy keys UI.
[ Parent | on HN ]
Re:Read-only deploy keys by BillinghamJ on Wednesday June 17, 2015 @03:45AM (#9730483)
However Github doesn't actually have support for "machine users" - they're just normal user accounts with full GUI access on Github.com.

And if you are on Github's per-user pricing model, machine users are not free.

[ Parent | on HN ]
Re:Read-only deploy keys by novaleaf on Wednesday June 17, 2015 @08:08AM (#9731226)
This is exactly what I do on bitbucket (which has had read only repo keys for a while) as repo keys are kind of a pain to use.
[ Parent | on HN ]
Re:Read-only deploy keys by nitrogen on Tuesday June 16, 2015 @09:56PM (#9729720)
Machine users work pretty well for this. You can grant R/O access to a repo to the machine user.
[ Parent | on HN ]
Re:Read-only deploy keys by baudehlo on Tuesday June 16, 2015 @10:02PM (#9729735)
You can, but the interface for doing so is significantly more annoying.
[ Parent | on HN ]
Re:Read-only deploy keys by MatthewWilkes on Tuesday June 16, 2015 @04:31PM (#9728513)
Deploy keys weren't read-only already? Seriously?
[ Parent | on HN ]
Re:Read-only deploy keys by mdaniel on Tuesday June 16, 2015 @04:43PM (#9728572)
I don't know about your use-case, but in my experience by far the greatest use of these keys is (as they say in the linked article) for use by continuous integration servers. Some folks tag each build (if it creates an artifact), and almost everyone tags release builds created by CI. Thus, these keys need to be R/W to push tags back up.
[ Parent | on HN ]
Re:Read-only deploy keys by ctz on Tuesday June 16, 2015 @05:26PM (#9728798)
Pushing a new tag is a vastly smaller privilege than pushing arbitrary objects.
[ Parent | on HN ]
Re:Read-only deploy keys by myhf on Tuesday June 16, 2015 @05:40PM (#9728875)
Actually, pushing objects is a smaller privilege.
[ Parent | on HN ]
Re:Read-only deploy keys by Dylan16807 on Tuesday June 16, 2015 @05:50PM (#9728926)
Fine, let's be picky. Pushing a new tag onto an existing commit is a vastly smaller privilege than being able to push objects and point branches at them.
[ Parent | on HN ]
Re:Read-only deploy keys by eeeeeeeeeeeee on Tuesday June 16, 2015 @11:23PM (#9729919)
You can have a read-write user on your CI server, but use a read-only user for any remote server where code is deployed. It's bad security policy that GitHub ever allowed deploy keys to be RW.
[ Parent | on HN ]
Re:Read-only deploy keys by DannyBee on Tuesday June 16, 2015 @04:57PM (#9728646)
https://developer.github.com/v3/git/tags/

Use API + oauth access?

[ Parent | on HN ]
Re:Read-only deploy keys by bobfunk on Tuesday June 16, 2015 @05:45PM (#9728904)
API access is a lot more permissive. A deploy key only have access to 1 repo, but there's no way to limit API tokens to a single repo (and by default they have access to all repos in all organizations the issuer of a token have access to).
[ Parent | on HN ]
Re:Read-only deploy keys by DannyBee on Tuesday June 16, 2015 @06:26PM (#9729095)
Yes, I didn't realize how bad github's security model of this stuff was.
[ Parent | on HN ]
Re:Read-only deploy keys by Danack on Tuesday June 16, 2015 @08:26PM (#9729461)
Yeah, it's terrible.

You can't give read only Oauth access to private repos....it has to be read/write. Which means if you want to use online CI tools with those private repos....you've got to hope they don't either turn malicious, or they get hacked and have their keys copied.

[ Parent | on HN ]
Re:Read-only deploy keys by icebraining on Tuesday June 16, 2015 @05:51PM (#9728929)
Can you limit the user permissions to only affect tags? Otherwise, I'm not seeing the advantage.

From what I can tell, there's no write:tags scope: https://developer.github.com/v3/oauth/#scopes

[ Parent | on HN ]
Re:Read-only deploy keys by DannyBee on Tuesday June 16, 2015 @06:26PM (#9729093)
Ugh. You are right, it looks like they screwed this up.
[ Parent | on HN ]
Re:Read-only deploy keys by sytse on Wednesday June 17, 2015 @05:26AM (#9730753)
I don't understand, won't you tag a release commit first manually and than have it be created by the CI server?
[ Parent | on HN ]
Re:Read-only deploy keys by llasram on Wednesday June 17, 2015 @05:46AM (#9730805)
Some people using manual tagging as a mechanism to communicate something to CI as you suggest, but others let CI tag successful builds. When I re-did my team's CI a few years ago I chose the latter because it creates less friction for continuous deployment -- every commit which passes the tests automatically becomes a deployable artifact with a monotonically increasing build number which can be tracked across SCM, CI, and deployment.
[ Parent | on HN ]
Re:Read-only deploy keys by sytse on Wednesday June 17, 2015 @06:54AM (#9730983)
Why not use the sha as the build identifier across SCM, CI and deployment? It exists already.
[ Parent | on HN ]
Re:Read-only deploy keys by mdaniel on Wednesday June 17, 2015 @04:22PM (#9734982)
Heh, you've never worked with a project/product manager, have you? "Yes, ma'am, version 1b6411f has been deployed successfully. Now I just need to edit the pom and bump the version to 2e1080d"
[ Parent | on HN ]
Re:Read-only deploy keys by sytse on Thursday June 18, 2015 @08:13AM (#9738053)
Good point, but if you bump the version yourself why not set a tag?
[ Parent | on HN ]
Re:Read-only deploy keys by DannyBee on Tuesday June 16, 2015 @04:54PM (#9728632)
I never understood why nobody cared. We had banned use of deploy keys on our repos precisely because they weren't read-only.
[ Parent | on HN ]
Re:Read-only deploy keys by hobarrera on Tuesday June 16, 2015 @08:11PM (#9729412)
They're not really "deploy-only" keys, but rather "automation keys".

Personally, I've used them a lot to mirror from my own gitlab server onto github, so having them be read+write was a good thing in my case.

I know a lot more people use them to mirror stuff onto gh as well.

[ Parent | on HN ]
Re:Read-only deploy keys by vacri on Tuesday June 16, 2015 @05:50PM (#9728922)
Yep, and there was a big fat warning in the documentation saying that they had full access to the repo. Couple this with being able to be used on only a single repo - github blocks other repos from using the same key - and you may as well just make a normal github account for your deploy system and manage it that way...

It's weird that they didn't have an option to write only for tags. "CI build X"...

[ Parent | on HN ]
Re:Read-only deploy keys by kurttheviking on Tuesday June 16, 2015 @06:24PM (#9729082)
Yeah, one or more deployment accounts is the approach I've seen most "in the wild". Machine users[1] with tightly scoped access to a collection of repos. Access can then be managed through the relevant Read-only GitHub team.

[1] https://developer.github.com/guides/managing-deploy-keys/#ma...

[ Parent | on HN ]
Re:Read-only deploy keys by eeeeeeeeeeeee on Tuesday June 16, 2015 @11:21PM (#9729915)
It's ridiculous it has taken GitHub so long to provide this basic functionality. Judging by comments on this thread, it looks like a lot of people assumed the keys were already read-only. And i'm not surprised because GitHub has never made it explicitly clear in documentation and their website that the keys had full write access!

I stopped using deploy keys long ago because of the security issue and instead opted to create additional github users with read-only access for each use case.

Why did GitHub call these "deploy" keys if they had write access? Why would a deploy user need full write privileges to a repository to deploy something?

[ Parent | on HN ]
Re:Read-only deploy keys by gkop on Wednesday June 17, 2015 @01:35AM (#9730213)
I asked Zach Holman at one of his tech talks a couple years ago and he replied (paraphrasing): "Yes read/write deploy keys are not ideal. That's why we don't ourselves use deploy keys at GitHub, and in fact we regret that the feature exists." I think he used an expression like "deploy keys are a red-headed stepchild".
[ Parent | on HN ]
Re:Read-only deploy keys by holman on Wednesday June 17, 2015 @01:41AM (#9730225)
I like to pride myself on never having used a clumsy phrase like that. That said, machine users were en vogue at GitHub, although maybe that's changing with more consideration being given to deploy keys nowadays.
[ Parent | on HN ]
Re:Read-only deploy keys by gkop on Wednesday June 17, 2015 @01:48AM (#9730239)
Sorry, I believe you used a more palatable expression than that, but having a similar meaning.

Edit: and to paint a more complete picture, you pointed out in your answer that many folks were using deploy keys to promote from a development branch to the master branch. Some commenters in this thread may, like myself, just not have thought to use deploy keys for this purpose, or that others would want to.

[ Parent | on HN ]
Re:Read-only deploy keys by chrisfosterelli on Tuesday June 16, 2015 @04:39PM (#9728553)
Agreed, I actually thought that was the main point of this feature the whole time.
[ Parent | on HN ]
Re:Read-only deploy keys by tjbiddle on Tuesday June 16, 2015 @10:20PM (#9729788)
Yikes - seriously, I had always thought deploy keys were read-only by definition.
[ Parent | on HN ]
Re:Read-only deploy keys by nilved on Tuesday June 16, 2015 @09:34PM (#9729654)
My thought exactly. I thought deploy keys were deploy keys because they were read-only. I don't think this is a feature announcement as much as a CVE.
[ Parent | on HN ]
Re:Read-only deploy keys by codyps on Tuesday June 16, 2015 @08:33PM (#9729486)
Now we just need branch restricted keys & keys that aren't allowed to force push (both of these would make me feel a lot better about using certain 3rd party automation in combination with my github repos).

Not that I really expect that to happen anytime soon, I believe others have been asking for the above for quite some time.

[ Parent | on HN ]
Re:Read-only deploy keys by datajeroen on Tuesday June 16, 2015 @05:04PM (#9728687)
I asked this question 5 years ago on SO: http://stackoverflow.com/questions/2868432/github-readonly-a.... Glad it got addressed.
[ Parent | on HN ]
Re:Read-only deploy keys by andmarios on Tuesday June 16, 2015 @04:42PM (#9728565)
I always thought that deploy keys are read-only. I can't understand why one would need a special interface to add a read-write key that is the same as any other key you add manually.

Iirc only the owner can create deploy keys, so it wasn't a feature aimed to teams either.

[ Parent | on HN ]
Re:Read-only deploy keys by TimWolla on Tuesday June 16, 2015 @05:32PM (#9728834)
They are not tied to a specific, potentially personal, GitHub account.
[ Parent | on HN ]
Re:Read-only deploy keys by jtchang on Tuesday June 16, 2015 @05:33PM (#9728842)
Deploy keys could only exist in one repo at a time. And I think a lot of people thought they were read only.
[ Parent | on HN ]
Re:Read-only deploy keys by renke1 on Tuesday June 16, 2015 @04:20PM (#9728456)
I would love to see auth token that provide read-only access to select repositories. I find SSH keys much harder to use in a Docker-based deployment.
[ Parent | on HN ]
Re:Read-only deploy keys by icebraining on Tuesday June 16, 2015 @05:57PM (#9728954)
Couldn't you create a new user, give it access to those chosen repositories, and then use the API to access them with read-only permissions?
[ Parent | on HN ]
Re:Read-only deploy keys by detaro on Tuesday June 16, 2015 @07:51PM (#9729368)
If I'm not mistaken you can't grant an application read-only access to a repository? GitHub really isn't very granular in their permissions...
[ Parent | on HN ]
Re:Read-only deploy keys by yeukhon on Tuesday June 16, 2015 @10:00PM (#9729732)
Not sure the best route, but the ugly route I know of is place the user in a group wich just have read-only. I am really shocked GH doesn't actually make role-based more granular. I have to add a group to a repository, and can't have the option now to add user to a repository....
[ Parent | on HN ]