4 ms·

> The GitHub MCP is definitely at fault. It shouldn't allow any mixed interactions across public and private repos These are separate tool calls. How could the

> The GitHub MCP is definitely at fault. It shouldn't allow any mixed interactions across public and private repos These are separate tool calls. How could the MCP server know that they interact at all?

kiitos 1y ago
I dunno! But if it can't, then it can't allow itself to be instantiated in a way that allows these kinds of mixed interactions in the first place.
- vel0city 1y ago
  The GitHub API could also have the same effects if you wired up some other automated tool to hit it with a token that can access private and public repos. Is the GitHub API also at fault for having the potential for these mixed interactions? Say you had a Jenkins build server and you gave it a token which had access to your public and private repos. Someone updates a Jenkinsfile which gets executed on PRs to run automated tests. They updated it to read from a private repo and write it out someplace. Is this the fault of Jenkins or the scoping of the access token you gave it?
  - kiitos 1y ago
    GitHub provides the GitHub MCP server we're discussing right now. That tool allows interactions that violate the access control constraints defined by GitHub itself. If you wired up "some other automated tool" to the GitHub API, and that tool violated GitHub access control constraints, then the problem would be in that tool, and obviously not in the API. The API satisfies and enforces the access control constraints correctly. A Jenkins build server has no relationship with, or requirement to enforce, any access control constraints for any third-party system like GitHub.
    - vel0city 1y ago
      > violate the access control constraints defined by GitHub itself. I don't see anything defining these access control constraints listed by the MCP server documentation. It seems pretty obvious to me its just a wrapper around its API, not really doing much more than that. Can you show me where it says it ensures actions are scoped to the same source repo? It can't possibly do so, so I can't imagine they'd make such a promise. GitHub does offer access control constraints. Its with the token you generate for the API.
      - kiitos 1y ago
        The token you provide to the GitHub official MCP server determines what that server is allowed to access. But the MCP server doesn't just serve requests with responses, which is the normal case. It can read private data, and then publish that private data to something that is outside of the private scope, e.g. is public. This is a problem. The system doesn't need to make an explicit promise guaranteeing that this kind of stuff isn't valid, it's obviously wrong, and it's self-evident that it shouldn't be allowed.
        wlamartin 1y ago
        I'm not sure whether you're confused, or I'm just having a horrible time understanding your point. The MCP server really does just serve requests with responses via a mechanism that satisfies the MCP spec. The MCP hosts (e.g. VSCode) work with an LLM to determine which of those tools to call, and ideally work with users via confirmation prompts to ensure the user really wants those things to happen. What am I missing? I do believe there's more that the MCP Server could be offering to protect users, but that seems like a separate point.
        kiitos 1y ago
        Sorry, I probably was being imprecise. You're correct that the [GitHub] MCP server really does serve requests with responses. But my point was that certain kinds of requests (like create_new_pr or whatever) have side effects that make mutating calls to third-party systems, and the information that can be passed as part of those mutating calls to those third-party systems isn't guaranteed to satisfy the access control expectations that are intuitively expected. Specifically by that I mean calling create_new_pr might target a public repository, but include a body field with information from a private repo. That's a problem and what I'm talking about.

kiitos 1y ago

I dunno! But if it can't, then it can't allow itself to be instantiated in a way that allows these kinds of mixed interactions in the first place.

vel0city 1y ago
The GitHub API could also have the same effects if you wired up some other automated tool to hit it with a token that can access private and public repos. Is the GitHub API also at fault for having the potential for these mixed interactions? Say you had a Jenkins build server and you gave it a token which had access to your public and private repos. Someone updates a Jenkinsfile which gets executed on PRs to run automated tests. They updated it to read from a private repo and write it out someplace. Is this the fault of Jenkins or the scoping of the access token you gave it?
- kiitos 1y ago
  GitHub provides the GitHub MCP server we're discussing right now. That tool allows interactions that violate the access control constraints defined by GitHub itself. If you wired up "some other automated tool" to the GitHub API, and that tool violated GitHub access control constraints, then the problem would be in that tool, and obviously not in the API. The API satisfies and enforces the access control constraints correctly. A Jenkins build server has no relationship with, or requirement to enforce, any access control constraints for any third-party system like GitHub.
  - vel0city 1y ago
    > violate the access control constraints defined by GitHub itself. I don't see anything defining these access control constraints listed by the MCP server documentation. It seems pretty obvious to me its just a wrapper around its API, not really doing much more than that. Can you show me where it says it ensures actions are scoped to the same source repo? It can't possibly do so, so I can't imagine they'd make such a promise. GitHub does offer access control constraints. Its with the token you generate for the API.
    - kiitos 1y ago
      The token you provide to the GitHub official MCP server determines what that server is allowed to access. But the MCP server doesn't just serve requests with responses, which is the normal case. It can read private data, and then publish that private data to something that is outside of the private scope, e.g. is public. This is a problem. The system doesn't need to make an explicit promise guaranteeing that this kind of stuff isn't valid, it's obviously wrong, and it's self-evident that it shouldn't be allowed.
      - wlamartin 1y ago
        I'm not sure whether you're confused, or I'm just having a horrible time understanding your point. The MCP server really does just serve requests with responses via a mechanism that satisfies the MCP spec. The MCP hosts (e.g. VSCode) work with an LLM to determine which of those tools to call, and ideally work with users via confirmation prompts to ensure the user really wants those things to happen. What am I missing? I do believe there's more that the MCP Server could be offering to protect users, but that seems like a separate point.
        kiitos 1y ago
        Sorry, I probably was being imprecise. You're correct that the [GitHub] MCP server really does serve requests with responses. But my point was that certain kinds of requests (like create_new_pr or whatever) have side effects that make mutating calls to third-party systems, and the information that can be passed as part of those mutating calls to those third-party systems isn't guaranteed to satisfy the access control expectations that are intuitively expected. Specifically by that I mean calling create_new_pr might target a public repository, but include a body field with information from a private repo. That's a problem and what I'm talking about.