vscode-copilot-release
vscode-copilot-release copied to clipboard
microsoft
Support Scoped permissions to Singular Organization or Repo
Currently Github Chat is requesting access to all repositories and organizations. This is difficult for people who use Github outside and inside of work settings. It doesn't allow them to scope Co-Pilot to their particular needs. Likewise, it creates host of legal questions on whether employers can force this product and the impact on private personal repositories/out of work activities.
https://github.com/microsoft/vscode-copilot-release/issues/813#issuecomment-1971105304
- VS Code Version: 1.87.0
- OS Version: Ventura 13.4.1
- Logs:
Steps to Reproduce:
- Open VsCode with latest copilot
- Click allow on model prompt
- See it request access to all repos and organizations
Specifically, the extension is requesting 'repo' scope which includes read/access to all public, private repos and many associated settings. Obviously for lots of folks this a non-starter.
The reasoning provided by @TylerLeonhardt (link)
We need the extra permissions (repo) in order to use a GitHub Search API because without it, it says the repo doesn't exist. GitHub doesn't split up repo permissions into read and write for this, unfortunately so we ask for the scope required to do the job.
Hopefully alternate permission scope(s) or access methods can be identified.
Unfortunately, we cannot do this at this time. We use a GitHub OAuth App and it doesn't and won't support the granularity of access per-repo.
After numerous discussions with GitHub, they have recommended that we continue being a GitHub OAuth app and that GitHub Apps, which support this granularity, are not viable for us to switch to at this time.
Our hands are tied with what GitHub offers.
I have continued asking for a a scope that doesn't have write permission, but it's non-trivial for them so I'm working with them to come up with a good plan
@TylerLeonhardt is there a ticket or issue that can tracked with Github OAuth? I understand that this might not being achieved quickly. However, this is something that should be pushed for
I am trying to phrase this in a constructive manner, but this ultimately limits the viability of CoPilot for many. If copilot ever stops working and I can't use it without giving it total access, I fully plan to stop using CoPilot. I know there a performance improvement doing it server-side, but can there a continued fallback to just use the local system for CoPilot?
Could this permission be asked for at the time when the Github Copilot Chat extension needs to use the github search api? The extension seems to work fine without granting this permission.
Unfortunately, we cannot do this at this time. We use a GitHub OAuth App and it doesn't and won't support the granularity of access per-repo.
You don't strictly need these permissions unless you really plan to make github copilot only to be usable within a github repostory. with no way to use it in non github repositories (or non repo files in general).
@TylerLeonhardt could a good fallback if permission is denied to use the local filesystem/plane git and/or the Github Search API? I'm interested in your thoughts here. I know the Github OAuth is lacking some Least Privilege Access, but I think these would be reasonable solutions to that.
Likewise, could a config be add to disable this in the vscode editor via the settings.json.
Could this permission be asked for at the time when the Github Copilot Chat extension needs to use the github search api? The extension seems to work fine without granting this permission.
Unfortunately, we cannot do this at this time. We use a GitHub OAuth App and it doesn't and won't support the granularity of access per-repo.
After numerous discussions with GitHub, they have recommended that we continue being a GitHub OAuth app and that GitHub Apps, which support this granularity, are not viable for us to switch to at this time.
Our hands are tied with what GitHub offers.
I have continued asking for a a scope that doesn't have write permission, but it's non-trivial for them so I'm working with them to come up with a good plan
If the scopes to read private repositories are necessary for the Search API with Copilot to work, and it will only be used when users with a GitHub Copilot Enterprise plan do a search via the Copilot Chat, isn't it better to ask for the extra permissions at that point?
There are two ways this can be solved:
- Allowing users to install GitHub Copilot OR GitHub Copilot Chat (or both) and only ask for these extra permissions if they install the chat extension (and leave the basic permissions for the other extension).
- Only require the extra permissions when triggering a Search API query with Copilot (only Enterprise users will need it, at least for now).
In my opinion, integrating those two solutions together is the way to go, but one is sufficient for now.
The easiest one to implement would be the first one, why both extensions needs to be installed?
It shouldn't be that complicated to at least give that choice to the users, while you wait for GitHub to implement more granular scopes to OAuth Apps or while users wait for improvements as the second solution I mention above or the plan you're referring to.
There is literally no reason Microsoft should be asking for write permissions to your private work repos.
In particular the ability to modify Deploy Keys, Webhooks and Collaborators are a non-starter for any maintainer with half a brain.
I will not be using copilot until these issues are resolved and I encourage others to boycott it too.
https://en.wikipedia.org/wiki/Principle_of_least_privilege
I get Github/Microsoft wants to increase the data available to train LLMs/CoPilot. However, it really does paint copilot as an insidious trojan horse. I'm wondering if developers and companies should be more concerned about copilot.
There are viable workarounds, and the lack of engagement from this team indicates the nefarious intent!