Mercurial用户管理和安全性

Question

我刚刚在Centos 5.5 x64服​​务器上安装了Mercurial 1.9.3.我正在使用hgweb.wsgi和发布我的存储库mod_wsgi.

此服务器仅供我们的内部代码库和开发团队使用,因此我还使用.htaccess基本HTTP身份验证保护我的服务器.这一切都很好,我可以将存储库克隆到本地并将更改推送回中央存储库.

有一件事我不能正确理解是如何控制和管理用户的.

例如,我的中央存储库服务器.htpassword文件中有两个用户:bob和kevin.

在每一个的bob和kevin的本地计算机上他们有自己的Mercurial .hgrc文件及其username配置的设置.

但是,这些.hgrc用户似乎与远程服务器.htpassword文件中指定的用户完全没有关系.

这意味着我最终可以推送到来自"米老鼠"和"唐老鸭"的中央存储库,这是无用的.

如何强制本地.hgrc用户名的端到端映射到.htpassword用户维护,即确保指定.hgrc的.htpassword用户匹配用户？

Answer 1

这不是一个答案,但值得一提的是:每个人一开始都担心这一点,但实际上这不是问题.

当用户提交DVCS时,无论是Mercurial,git还是其他,他们不一定连接到您控制的任何身份验证/授权系统,因此他们的提交必须(本地)提交他们想要的任何作者信息断言.您可以稍后将这些更改集拒绝push到您控制的repo/server上,但这对您和他们来说都是一个很大的麻烦.这不仅仅是重新设置他们的名称/密码,他们必须改变该变更集的历史记录以及所有后续变更集以更改作者信息.

完全不满意的解决方案列表是:

• 拒绝推送变更集作者身份与使用钩子的经过身份验证的用户不匹配(实际上这很糟糕,因为开发人员互相拉扯并一直推送彼此的变更集)
• 让开发人员使用gpg扩展或hgsigs签署他们的变更集(一个巨大的麻烦,他们会忘记)
• 在服务器上保留一个pushlog记录经过身份验证的用户,该用户将每个变更集与其作者分开(Mozilla这样做,并且它不像其他人那样麻烦,但仍然不太可能被咨询).

如果您肯定不能冒险进入特定仓库的伪造变更集,那么使用人工过滤器,人们推送到共享仓库A,只有审查员/ buildmanager /您可以从仓库A推送到回购B,其中回购B是官方构建来自的地方.Mercurial本身使用这个系统.

最后我的建议是不要担心.值得招聘的开发人员很自豪地将他们的名字写在他们的承诺上,如果你没有值得雇佣的开发人员,你已经注定要失败了.