有什么方法可以保证git用户在提交和推送时不使用虚假账户信息？

Question

由于git用户可以自由配置他们的user.name和user.email并进行提交,因此John可能使用Bob的名字和电子邮件伪造提交,这不是我们想要的.有什么方法可以防止这种情况吗？我知道在svn中我们需要用户名和密码来提交; Git中有没有相同的机制？

Answer 1

另一种方法，也基于签名的 gpg，是对推送操作本身进行签名（而不是对象，如标签或提交）

这就是 Git 2.2（2014 年 11 月）和 Git 2.2（2014 年第 4 季度）的提议。

它允许对“ git push” ^（man）请求进行签名，以便可以使用推送者的 GPG 签名对其进行验证和审计，公共存储库中的分支提示确实指向推送者想要的提交，而无需必须“信任”服务器。

请参阅提交 5732373（2014 年 9 月 5 日）、提交 0ea47f9（2014 年 9 月 15 日）、提交 b89363e（2014 年 8 月 21 日）、提交 9be8916（2014 年 8 月 22 日）、提交 4adf569、提交 20a7558（2014 年 8 月 18 日）、提交 d05b961、提交 a50e 7ca（ 2014年8月14日），提交a85b377（2014年9月12日），提交e543b3f，提交d7c6766，提交c67072b（2014年8月19日），提交b783aa7，提交ab2b0c9，提交887f353，提交64de20a，提交39895c7 ，提交c 09b71c ，提交0e3c339，提交 3bfcb95（2014 年 8 月 15 日）、提交 52d2ae5（2014 年 9 月 4 日）、提交 e40671a、提交 621b059（2014 年 8 月 12 日），作者：Junio C Hamano ( )。 请参阅Brian Gernhardt ( )的提交 6f5ef44（2014 年 9 月 25 日）。^{（由Junio C Hamano 合并 -- --在提交 fb06b52，2014 年 10 月 8 日）}gitster
bgernhardt
gitster

push：“git push --signed”的开头

虽然签名的标签和提交断言如此签名的对象来自您，您签署了这些对象，但没有一个好的方法来断言您希望在特定分支的顶端拥有特定的对象。
我的签名 v2.0.1 标签仅意味着我想调用版本 v2.0.1，并不意味着我想将其推送到我的“master”分支——很可能我只想将它放在“maint”中，因此仅在对象上签名是不够的。

向您保证“维护”指向我想要放置的内容的唯一保证来自您对托管站点的信任以及我对其进行的身份验证，这在以后无法轻易审核。

引入一种机制，允许您在每次推送时签署“推送证书”（由于缺乏更好的名称），断言您要推送的对象来更新用于指向其他对象的引用。
将其视为引用更新的加密保护，类似于签名标签/提交，但在正交轴上工作。

基于该机制的基本流程如下：

1. git push你用“ ” ^（man） --signed”来推出你的工作。
2. 发送方像往常一样了解远程引用的位置，以及接收端支持的协议扩展。
   如果接收端不通告协议扩展“push-cert”，则尝试“ git push --signed” ^{( man )}失败。

否则，将在 core 中准备一个如下所示的文本文件：

certificate version 0.1
pusher Junio C Hamano <gitster@pobox.com> 1315427886 -0700

7339ca65... 21580ecb... refs/heads/master
3793ac56... 12850bec... refs/heads/next

该文件以一些标题行开始，随着我们获得更多经验，标题行可能会增加。
' pusher' 标头记录了签名者的姓名（user.signingkey 配置变量的值，回落到GIT_COMMITTER_{NAME|EMAIL}）和证书生成的时间。
标头之后是一个空行，后面是协议消息行的副本。

每行都显示此推送尝试更新的引用顶部的旧对象名称和新对象名称，其方式与底层“git Push”协议交换告诉接收端引用更新的方式相同（通过记录“旧对象”） “对象名称，推送证书还可以防止重放）。

预计除 old-new-refname 类型之外的新命令数据包类型将包含在推送证书中，其方式与未签名推送中的普通命令数据包中出现的方式相同。

然后，要求用户使用 GPG 签署此推送证书，其格式类似于签名标签对象的签名方式，并将结果发送到另一方（即接收包）。

在协议交换中，此步骤紧接在发送方告诉推送结果应该是什么之前，而发送方又在发送包数据之前发生。

3. 当接收端看到推送证书时，该证书会以 blob 形式写出。
   预接收钩子可以通过检查环境变量来了解证书GIT_PUSH_CERT，如果存在，则告知该 blob 的对象名称，并决定允许或拒绝该推送。
   此外，接收后挂钩还可以查看证书，这可能是记录所有收到的证书以供以后审核的好地方。

由于推送证书携带的信息与协议交换中通常的命令报文相同，因此在使用推送证书时我们可以省略后者，减少协议开销。
然而，这并没有包含在这个补丁中，以便更容易审查（换句话说，在没有该系列的其余部分的情况下，这一步的系列永远不应该发布，因为它实现了一个与最终协议不兼容的临时协议） 。
因此，该步骤中省略了协议的文档更新。

config现在包含在其手册页中：

receive.acceptpushcert

默认情况下，git receive-pack将通告它接受git push --signed.
将此变量设置为 false 会禁用它（这是一个暂定变量，将在本系列结束时消失）。

git push现在包含在其手册页中：

[--repo=] [-f | --force] [--prune] [-v | --prune] --详细] [-u | --设置上游] [--签名]

git push现在包含在其手册页中：

--signed

GPG 对推送请求进行签名以更新接收端的引用，以允许钩子检查和/或记录它。git receive-pack有关接收端的详细信息，请参见参考资料。

git receive-pack现在包含在其手册页中：

当接受签名推送时（请参阅 参考资料git push），签名推送证书存储在 blob 中，并且 GIT_PUSH_CERT可以查阅环境变量来获取其对象名称。示例
请参见钩子的描述。post-receive

git receive-pack现在包含在其手册页中：

在接受签名推送后，GIT_PUSH_CERT可以像在钩子中一样检查环境变量。pre-receive

git receive-pack现在包含在其手册页中：

ref 列出推送到存储库的提交，并将签名推送的推送证书记录到记录器服务：

git receive-pack现在包含在其手册页中：

记录签名的推送证书（如果有）

if test -n "${GIT_PUSH_CERT-}"
then
(
    git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "push certificate" push-log@mydomain
fi