5 ms·
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 integr
by mdaniel 11y ago
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.
- DannyBee 11y agohttps://developer.github.com/v3/git/tags/ https://developer.github.com/v3/git/tags/ Use API + oauth access?
- bobfunk 11y agoAPI 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).
- DannyBee 11y agoYes, I didn't realize how bad github's security model of this stuff was.
- Danack 11y agoYeah, 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.
- icebraining 11y agoCan 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 https://developer.github.com/v3/oauth/#scopes
- DannyBee 11y agoUgh. You are right, it looks like they screwed this up.
- ctz 11y agoPushing a new tag is a vastly smaller privilege than pushing arbitrary objects.
- myhf 11y agoActually, pushing objects is a smaller privilege.
- Dylan16807 11y agoFine, 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.
- eeeeeeeeeeeee 11y agoYou 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.
- sytse 11y agoI don't understand, won't you tag a release commit first manually and than have it be created by the CI server?
- llasram 11y agoSome 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.
- sytse 11y agoWhy not use the sha as the build identifier across SCM, CI and deployment? It exists already.