get_file_contents directory listings put tokenised private-repo download URLs in model context

未关闭
  • 哪里不对？
#3,748 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 2 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
67/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
github, go
领域
backend-api-design, security

调研方向

Start in pkg/github/repositories.go and trace how directory entries are rendered, including how the fields parameter uses fileContentFieldEnum. Check the large-file message that explicitly tells callers to use the download URL. Done when directory listings omit or strip the tokenized URL by default, explicit field requests can still include it, and the large-file path retains its download URL.

由索引模型根据 Issue 内容生成。

描述

enhancement
Describe the feature or problem you’d like to solve

Low-severity hardening suggestion (not a vulnerability report).

In v2.1.0, get_file_contents on a directory of a private repository returns, for every entry, a download_url of the form https://raw.githubusercontent.com/<owner>/<repo>/<sha>/<path>?token=… in the model-visible text. That URL fetches the file with no other authentication for a short time (a few minutes in my tests, and it worked more than once); without the token parameter it returns 404.

The REST contents API itself returns this URL, so the server is passing it through rather than creating it. But for a directory listing the model rarely needs a credential-bearing URL for every file, and it is the one field in the listing that grants access on its own. If an agent is steered by untrusted content (prompt injection) into copying it somewhere public, anyone can fetch that private file for the next few minutes. The marginal risk is small, since a hijacked agent could also read and paste the file, but the URL is a bearer credential the model doesn’t need.

For files of 1 MB or more, get_file_contents also tells the model to use the download URL (pkg/github/repositories.go, the File %s is too large to display … Use the download URL message), which is a reasonable place to keep it.

Proposed solution
  • Omit download_url (or strip its token query parameter) from directory listings by default; callers that need it can already ask for it through the fields parameter (download_url is in fileContentFieldEnum).
  • Keep the explicit download URL for the large-file path, where the model is meant to use it.

Benefit: one less bearer credential in model context and in client logs/transcripts, with no loss of function.

Example prompts or workflows (for tools/toolsets only)
  1. "List the files in src/ of my private repo" — needs names, paths, sizes, SHAs; not per-file signed URLs.
  2. "Find the config file in this private repo and summarise it" — the agent lists the directory, then reads the file through the tool, never through the raw URL.
  3. Agent transcripts and MCP client logs that record tool output no longer contain short-lived access tokens for private files.
Additional context
  • Reproduced on v2.1.0 (ghcr.io/github/github-mcp-server@sha256:f6056fc10bfffcc8c81a6417a2e9ca12808647e8dd6049642a4feaadee0e0f8a), --read-only, fine-grained read-only token, against a throwaway private repo in an org I own. A src/ listing returned 4 entries, all with tokenised download_urls; an unauthenticated GET of one returned 200, the same URL without the token 404.
  • Found during an independent, AI-assisted review of v2.1.0; reproduced by hand.
主要语言
Go
星标
34.2k
派生
5.3k
平均合并
5 天 18 小时
30 天内合并 PR
13

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

github/github-mcp-server 的其他 Issue

查看 github/github-mcp-server 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。