Repository navigation
Travis CI setup in i18n group #243
Description
Hi.
We have some permission problem.
We recently migrated our repo https://github.com/nodejs/nodejs-ko to hexo.
After that, we need some CI since it is not supported by the GitHub pages.
So, I clicked request permission button at travis. and @ChALkeR got private request.
And we don't want private permission.
Is there any other way? Can we setup CI without got private permission? Please help us---
Metadata
Metadata
Assignees
Labels
No labels
Activity
ChALkeR commentedon Aug 8, 2016
/cc @nodejs/ctc
bnoordhuis commentedon Aug 8, 2016
I just replied to the GH notification but for the record, there doesn't appear to be a way to give Travis access without also giving it read access to private repositories.
Fishrock123 commentedon Aug 8, 2016
I'll set this up, I've done it for the other repos before. The setup is messy and does require giving temporary access to everything.
ChALkeR commentedon Aug 8, 2016
Btw, /cc @henrikhodne — this is not very nice usability- and security-wise. Perhaps something could be done about that on the Travis side?
bnoordhuis commentedon Aug 8, 2016
I don't think that is acceptable. Are you saying you've done this before?
Fishrock123 commentedon Aug 8, 2016
@bnoordhuis Yes. I will need to do it this week at least for the github bot so I might as well just do it for the Korean WG too.
Fishrock123 commentedon Aug 8, 2016
The process is something like:
ChALkeR commentedon Aug 8, 2016
@Fishrock123 That still sounds pretty bad. Is there a way to enable the repos manually on Travis (i.e. add hooks manually) if that doesn't require access to actually work?
bnoordhuis commentedon Aug 8, 2016
I'm really not pleased to hear about this. If Travis is compromised at the time of access, our private repositories are comprised. If we want to be strict about security, we should replace our infra's ssh keys.
/cc @nodejs/build
jasnell commentedon Aug 8, 2016
I agree with @bnoordhuis on this. I'm -1 to enabling travis this way.
Starefossen commentedon Aug 8, 2016
Infra keys managed in the private build repo are all encrypted to prevent a compromise in case of unauthorized access.
But giving Travis all access to everything sounds like a very bad idea in the first place.
Fishrock123 commentedon Aug 8, 2016
@ChALkeR Not reliably iirc.
It won't let you admin it without giving it access permission.
Choose one this week:
I'm going to get projects the CI access they need and we've done this before. So we need to do something about those because I'm not interested in this getting blocked up again. (we had this issue with the website and readable-stream for a long time)
Fishrock123 commentedon Aug 8, 2016
It is possible the private built repo did not exist last time.
jasnell commentedon Aug 8, 2016
-1 to options 1 and 2 (moving any of the repos out of the org). Until travis can be set up in such a way that does not requiring giving access to private repos, we simply should not enable travis.
2 remaining items
Fishrock123 commentedon Aug 8, 2016
Sorry, not an option. Projects have needed this and continue to need it and otherwise we'll need to at least move the github bot out of the org.
¯_(ツ)_/¯
bnoordhuis commentedon Aug 8, 2016
Does the GH bot run on our own infrastructure? The reason Travis is forbidden is that it's an external service that we have no control over and cannot audit (so please don't do that again.)
ChALkeR commentedon Aug 8, 2016
Based on reply from @henrikhodne, http://travis-ci.org should request access only to public repos.
Can we confirm that somehow on our side?
ChALkeR commentedon Aug 8, 2016
Note that «Travis CI for Private Projects» never got approved, «Travis CI» did several times.
bnoordhuis commentedon Aug 8, 2016
The requested access was this:
Read-only public access is not a problem, that doesn't require explicit permission.
ChALkeR commentedon Aug 8, 2016
@bnoordhuis That one is surely not needed, and that one was never approved. «Travis CI» was approved (and revoked) several times, though.
The thing is, that if I understand things correctly we can't verify the access level of any thirdparty application by the users — we could either allow the app or block the app. Allowing the app would allow it to use any scopes given by individual users, but we can't review or check those on the org side.
E.g. if «Application X» requested access from CTC member 1 for private repos, from CTC memeber 2 for public repos — we could either allow all of those or block all of those. We also don't see which scopes were requested or given to the app.
ChALkeR commentedon Aug 8, 2016
Btw, what could be done is: for each sensitive private repo, everyone who has access to that repo could confirm that the appication that we are giving temporary access (in this case, «Travis CI») doesn't have any scopes that would give that app access to private repos, once the org would enable that app. Each user with access to any of the private repos should do that individually.
I'm pretty sure that's the case for «Travis CI» (not the «Travis CI for Private Projects»), but we should check that.
bnoordhuis commentedon Aug 9, 2016
@ChALkeR That doesn't sound like a solution to me, that is basically crossing our collective fingers and hoping that the third-party service is never comprised or turns evil.
ChALkeR commentedon Aug 9, 2016
@bnoordhuis No, it's not. If the necessary precautions I described are taken, how exactly would it be possible to evade those to reach private repos?
bnoordhuis commentedon Aug 9, 2016
Wait, I think I understand the confusion. The page you link to describes scopes as a way for third-party services to voluntarily reduce their access token's, er, scope (the intersection of allowed_permissions_set and requested_permissions_set) but you are talking about handing out pre-generated access tokens from https://github.com/settings/tokens/new with reduced permissions.
outsideris commentedon Aug 30, 2016
Is there any progress?
marocchino commentedon Sep 25, 2016
Our team decide to use a private CI.
Feel free to close this. :3
bnoordhuis commentedon Sep 25, 2016
Thanks, I'll close.
ChALkeR commentedon Nov 28, 2016
Btw, https://developer.github.com/early-access/integrations/ should fix the security concerns about granting access to Travis, so when/if Travis adopts that, we could install Travis CI to repos on a per-repo basis.