关于命令行中的推送保护
推送保护通过阻止包含支持的机密的推送,防止你无意将机密提交到存储库。
尝试将受支持的机密从命令行推送到受推送保护保护的存储库时,GitHub 将阻止推送。
应该:
在命令行上,每次最多显示 5 个检测到的机密。 如果存储库中已检测到特定机密并且警报已存在,则 GitHub 不会阻止该机密。
如果确认机密是真实的,并且你打算稍后修补它,你应该致力于尽快修补机密。 例如,你可以撤销该机密,并从存储库的提交历史记录中删除机密。 必须撤销已公开的真实机密,以避免未经授权的访问。 在撤销机密之前,可以考虑先轮换机密。 有关详细信息,请参阅“从存储库中删除敏感数据”。
注释:
- 如果 Git 配置支持推送到多个分支,而不仅仅是推送到当前分支,则由于附加和意外的引用被推送,你的推送可能被阻止。 有关详细信息,请参阅 Git 文档中的
push.default
选项。 - 如果在推送超时后进行 secret scanning,GitHub 仍将在推送后扫描你的提交有无机密。
解决被阻止的推送
若要解决被阻止的推送,必须从其出现的所有提交中删除机密。
- 如果机密是由最新提交引入的,请参阅“删除分支上最新提交引入的机密”。
- 如果机密出现在先前提交中,请参阅“删除分支上先前提交引入的机密”。
Note
若要了解如何解决 GitHub UI 中被阻止的提交,请参阅“使用 GitHub UI 中的推送保护”。
删除分支上最新提交引入的机密
如果分支上的最新提交引入了阻止的机密,可以遵循以下指南进行操作。
- 从代码中删除机密。
- 若要提交更改,请运行
git commit --amend
。 这会更新引入机密的原始提交,而不是创建新提交。 - 使用
git push
推送更改。
删除分支上先前提交引入的机密
如果机密出现在 Git 历史记录的早期提交中,还可以将其删除。 为此,需要确定哪个提交首先引入了机密,并通过交互式变基修改提交历史记录。
-
检查尝试推送分支时显示的错误消息,其中列出了包含该机密的所有提交。
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
-
接下来,运行
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
-
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.
- In the example, commit
-
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
.
- For
-
In the editor, choose to edit the commit identified in step 3 by changing
pick
toedit
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
-
保存并关闭编辑器,以开始交互式变基。
-
从代码中删除机密。
-
使用
git commit --amend
提交更改。 -
运行
git rebase --continue
以完成变基。 -
使用
git push
推送更改。
绕过推送保护
如果 GitHub 阻止了你认为可以安全推送的机密,则你能够通过指定允许推送机密的原因来绕过阻止。
允许推送机密时,将在“安全性”选项卡中创建警报。如果指定机密为误报或仅在测试中使用,则 GitHub 会关闭警报,且不会发送通知。 如果指定机密是真实的并且稍后将修复它,GitHub 会将安全警报保持打开状态,并向提交的作者以及存储库管理员发送通知。 有关详细信息,请参阅“管理来自机密扫描的警报”。
当参与者绕过机密的推送保护块时,GitHub 还会向选择接收电子邮件通知的组织所有者、安全管理员和存储库管理员发送电子邮件警报。
如果看不到绕过阻止的选项,则存储库管理员或组织所有者已针对推送保护配置了更严格的控制。 相反,应从提交中删除机密,或提交“绕过特权”的请求以推送阻止的机密。 有关详细信息,请参阅 GitHub Enterprise Cloud 文档中的“请求绕过特权”。
-
当推送被阻止时,请访问 GitHub 返回的 URL。
-
选择最能描述为何应该能够推送机密的选项。
- 如果机密仅在测试中使用,并且不会构成任何威胁,请单击“它在测试中使用”。
- 如果检测到的字符串不是机密,请单击“它是误报”。
- 如果机密是真实的,但你打算稍后修复它,请单击“稍后修复”。
注意: 如果存储库启用了秘密扫描,则需要指定绕过推送保护的原因。
当推送到未启用机密扫描的_公共_存储库时,由于_用户的推送保护_(默认情况下,用户帐户处于启用状态),仍然可以防止意外推送机密。
通过用户的推送保护,如果公共存储库的推送包含受支持的机密,GitHub 将自动阻止这些推送,但无需指定允许该机密的原因,并且 GitHub 也不会生成警报。 有关详细信息,请参阅“用户的推送保护”。
-
单击“允许我推送此机密”。
-
在三个小时内在命令行上重新尝试推送。 如果三小时内未推送,则需要重复此过程。