13

尝试使用 git，我为自托管存储库设置了 Gitlab，它看起来很棒。

困扰我的一件事是，似乎任何人都可以像其他人一样进行提交（即：欺骗提交）。

即：我在 Gitlab 中设置了具有公钥访问权限的用户

  • 用户 1
  • 用户 2

现在只有那些用户可以推送 - 使用他们的私人 SSH 密钥 - 但似乎没有什么能阻止User2调整他们的 gitconfig 以以User1的名义提交并将其推送？

gitlab 和git -show中的历史将提交者显示为 User1 的 gitconfig 文本。我希望 Gitlab 将与推送 ssh 密钥关联的用户名标记到历史记录中，这样我就知道使用了谁的 ssh 密钥来推送。

场景是 repo 将在团队环境中使用，并且不允许欺骗提交似乎是谨慎的。

我已经阅读并了解，通常人们可能会更改工作流程以拥有一个有福的存储库，并且只有可以推动的受信任的提交者 - 但是在这个阶段，在学习 git 时，我想留在一个更集中/SVN 类型的工作流程中.

这可以使用钩子吗？

有一个类似的问题回答了 gitosis 但即使这似乎只强制提交者来自一系列用户，这些用户不会阻止 User1 欺骗为 User2 - 据我所知。

PS：也许我问错了问题——在 gitlab 中有没有办法发现哪个 ssh 密钥（以及真正的用户）被用来将代码推送到 repo 中？从我能找到的情况来看，情况并非如此。

4

1 回答 1

5

2015 年更新

正如这个线程所提到的，GitLab Enterprise 在其与项目相关的 git 钩子中提供了一种控制电子邮件的方法：

转到项目设置 - > git hooks 并检查作者电子邮件的验证。

任何与已知用户不匹配的电子邮件都会被拒绝。

原始答案（2012）

实现用户 id 控制的一种部分方法是，如果至少有一个推送的提交没有被推送的提交者提交，则让 gitolite（gitlab 所依赖的）拒绝推送。

当您推送时，您将获得身份验证（基于 Gitolite 注册的公钥名称，或通过 LDAP 连接等其他方式）。
您可以添加一个pre-receive钩子来检查所有新提交，并查找至少一个以正确名称（即推送所述提交的用户的 ID）提交的内容。
以这个pre-receive钩子为例。

于 2012-08-22T05:42:59.033 回答