Avoid exposing Git credentials in subprocess command-line arguments
まだ誰も着手していません。
評価
調査の方向性
Git のサブプロセス引数を構築し、認証情報を含む設定を処理するコードを見つけ、認可値とリポジトリ URL の検証を追跡してください。既存の GIT_CONFIG_* エントリや不正な形式のカウントを含め、子プロセスの環境がどのように組み立てられるかを確認してください。サブプロセス引数に認証情報が含まれず、設定の保持、検証、スコープ付き認可の動作が引き続きテストでカバーされていれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Description
Cachew currently passes repository-scoped authorization credentials to Git using command-line configuration:
git -c credential.helper=<helper containing credential> ...
The credential is embedded as a literal in the helper definition, which exposes it in Git's process arguments. Command-line arguments may be visible through process inspection tools, /proc/<pid>/cmdline, diagnostic tooling, or process telemetry.
PR #321 also identified that credentials are embedded in the helper command, but addressed token refresh during long-running subprocesses. It was closed in favor of #322, which addressed token lifetime and LFS timeouts without removing credentials from process arguments.
Proposed change
Pass credential-bearing Git configuration through Git's environment-based configuration mechanism instead:
GIT_CONFIG_COUNT=<n>
GIT_CONFIG_KEY_<n>=http.<repository-scope>.extraHeader
GIT_CONFIG_VALUE_<n>=Authorization: <credential>
The implementation should:
- Preserve existing
GIT_CONFIG_COUNT,GIT_CONFIG_KEY_*, andGIT_CONFIG_VALUE_*entries. - Append the credential configuration at the next available index.
- Reject malformed, negative, or overflowing
GIT_CONFIG_COUNTvalues. - Continue validating the authorization value and repository URL scope.
- Restrict this change to credential-bearing configuration; ordinary non-sensitive Git configuration can remain in command-line arguments.
- Ensure credentials do not appear in the generated Git subprocess arguments.
Security impact
This reduces accidental credential disclosure through process listings and command-line capture. The credential remains in the child process environment, as required by Git, so access to process environments should still be restricted appropriately.
- 主要言語
- Go
- スター
- 41
- フォーク
- 14
- 平均マージ
- 19時間 28分
- マージ済み PR（30日）
- 3
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
block/cachew のほかの issue
-
etag-range-followup
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
gruntwork-io/boilerplate#329 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
prime-radiant-inc/evener#3291 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Netcracker/qubership-apihub-backend#582 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信