从命令行使用推送保护

Learn your options for unblocking your push from the command line to GitHub if secret scanning detects a secret in your changes.

谁可以使用此功能？

具有管理员角色的存储库所有者、组织所有者、安全管理员和用户

本文内容

关于命令行中的推送保护

推送保护通过阻止包含支持的机密的推送，防止你无意将机密提交到存储库。

尝试将受支持的机密从命令行推送到受推送保护保护的存储库时，GitHub 将阻止推送。

应该：

在命令行上，每次最多显示 5 个检测到的机密。 如果存储库中已检测到特定机密并且警报已存在，则 GitHub 不会阻止该机密。

如果确认机密是真实的，并且你打算稍后修补它，你应该致力于尽快修补机密。 例如，你可以撤销该机密，并从存储库的提交历史记录中删除机密。 必须撤销已公开的真实机密，以避免未经授权的访问。 在撤销机密之前，可以考虑先轮换机密。 有关详细信息，请参阅“从存储库中删除敏感数据”。

注释：

  • 如果 Git 配置支持推送到多个分支，而不仅仅是推送到当前分支，则由于附加和意外的引用被推送，你的推送可能被阻止。 有关详细信息，请参阅 Git 文档中的 push.default 选项。
  • 如果在推送超时后进行 secret scanning，GitHub 仍将在推送后扫描你的提交有无机密。

解决被阻止的推送

若要解决被阻止的推送，必须从其出现的所有提交中删除机密。

Note

若要了解如何解决 GitHub UI 中被阻止的提交，请参阅“使用 GitHub UI 中的推送保护”。

删除分支上最新提交引入的机密

如果分支上的最新提交引入了阻止的机密，可以遵循以下指南进行操作。

  1. 从代码中删除机密。
  2. 若要提交更改，请运行 git commit --amend。 这会更新引入机密的原始提交，而不是创建新提交。
  3. 使用 git push 推送更改。

删除分支上先前提交引入的机密

如果机密出现在 Git 历史记录的早期提交中，还可以将其删除。 为此，需要确定哪个提交首先引入了机密，并通过交互式变基修改提交历史记录。

  1. 检查尝试推送分支时显示的错误消息，其中列出了包含该机密的所有提交。

    remote:   —— GitHub Personal Access Token ——————————————————————
remote:    locations:
remote:      - commit: 8728dbe67
remote:        path: README.md:4
remote:      - commit: 03d69e5d3
remote:        path: README.md:4
remote:      - commit: 8053f7b27
remote:        path: README.md:4

  2. 接下来，运行 git log 以查看分支上所有提交的完整历史记录及其对应的时间戳。

    test-repo (test-branch)]$ git log
commit 8053f7b27 (HEAD -> main)
Author: Octocat <1000+octocat@users.noreply.github.com
Date:   Tue Jan 30 13:03:37 2024 +0100

  my fourth commit message

commit 03d69e5d3
Author: Octocat <1000+octocat@users.noreply.github.com>
Date:   Tue Jan 30 13:02:59 2024 +0100

  my third commit message

commit 8728dbe67
Author: Octocat <1000+octocat@users.noreply.github.com
Date:   Tue Jan 30 13:01:36 2024 +0100

  my second commit message

commit 6057cbe51
Author: Octocat <1000+octocat@users.noreply.github.com
Date:   Tue Jan 30 12:58:24 2024 +0100

  my first commit message

  3. Focusing only on the commits that contain the secret, use the output of git log to identify which commit comes earliest in your Git history.

    • In the example, commit 8728dbe67 was the first commit to contain the secret.

  4. Start an interactive rebase with git rebase -i <COMMIT-ID>~1.

    • For <COMMIT-ID>, use the commit identified in step 3. For example, git rebase -i 8728dbe67~1.

  5. In the editor, choose to edit the commit identified in step 3 by changing pick to edit on the first line of the text.

    edit 8728dbe67 my second commit message
pick 03d69e5d3 my third commit message
pick 8053f7b27 my fourth commit message

  6. 保存并关闭编辑器，以开始交互式变基。

  7. 从代码中删除机密。

  8. 使用 git commit --amend 提交更改。

  9. 运行 git rebase --continue 以完成变基。

  10. 使用 git push 推送更改。

绕过推送保护

如果 GitHub 阻止了你认为可以安全推送的机密，则你或许能够通过指定允许推送机密的原因来绕过阻止。

允许推送机密时，将在“安全性”选项卡中创建警报。如果指定机密为误报或仅在测试中使用，则 GitHub 会关闭警报，且不会发送通知。 如果指定机密是真实的并且稍后将修复它，GitHub 会将安全警报保持打开状态，并向提交的作者以及存储库管理员发送通知。 有关详细信息，请参阅“管理来自机密扫描的警报”。

当参与者绕过机密的推送保护块时，GitHub 还会向选择接收电子邮件通知的组织所有者、安全管理员和存储库管理员发送电子邮件警报。

如果看不到绕过阻止的选项，则存储库管理员或组织所有者已针对推送保护配置了更严格的控制。 相反，应从提交中删除机密，或提交“绕过特权”的请求以推送阻止的机密。 有关详细信息，请参阅 GitHub Enterprise Cloud 文档中的“请求绕过特权”。

  1. 当推送被阻止时，请访问 GitHub 返回的 URL。

  2. 选择最能描述为何应该能够推送机密的选项。

    • 如果机密仅在测试中使用，并且不会构成任何威胁，请单击“它在测试中使用”。
    • 如果检测到的字符串不是机密，请单击“它是误报”。
    • 如果机密是真实的，但你打算稍后修复它，请单击“稍后修复”。

    注意： 如果存储库启用了秘密扫描，则需要指定绕过推送保护的原因。

    当推送到未启用机密扫描的_公共_存储库时，由于_用户的推送保护_（默认情况下，用户帐户处于启用状态），仍然可以防止意外推送机密。

    通过用户的推送保护，如果公共存储库的推送包含受支持的机密，GitHub 将自动阻止这些推送，但无需指定允许该机密的原因，并且 GitHub 也不会生成警报。 有关详细信息，请参阅“用户的推送保护”。

  3. 单击“允许我推送此机密”。

  4. 在三个小时内在命令行上重新尝试推送。 如果三小时内未推送，则需要重复此过程。

请求绕过特权

如果推送已被推送保护阻止，并且你认为推送机密是安全的，则可以请求绕过阻止的权限。 请求将发送给一组指定的审阅者，他们将批准或拒绝该请求。

请求会在 7 天后过期。

  1. 当推送被阻止时，请访问 GitHub 返回的 URL。
  2. 在“或请求绕过特权”下，添加注释。 例如，可以解释为什么你认为推送机密是安全的，或者提供有关绕过阻止的请求的上下文。
  3. 单击“提交请求”。
  4. 查看电子邮件通知以获取对请求的响应。

审查完你的请求后，你将收到一封电子邮件，通知你该决定。

如果请求获得批准，则可以将包含机密的提交以及包含同一机密的任何未来提交推送到存储库。

如果请求被拒绝，则在再次推送之前，需要从包含机密的所有提交中删除机密。 有关如何删除被阻止的机密的详细信息，请参阅“解决被阻止的推送”。

延伸阅读