git-cvsserver pserver 用户名传播

Question

对于我公司的一些特定工作流程问题，我需要允许一些用户工作 使用 CVS，而主存储库位于 git 下。

我选择 git-cvsserver 作为此任务的实现。

我设置了 git 存储库，为 gitcvs 启用它并在上设置了 pserver 模拟 西尼特。一切正常，我可以从 cvs 客户端使用这个存储库， 针对我通过 pserver 模拟创建的 passwd 文件进行身份验证。

我的问题是我通过 CVS 所做的提交显示在运行的用户下 xinetd，不在用户下，我根据 passwd 进行身份验证。

即我以用户“foo”的身份提交到 CVS，我通过 pserver 成功进行了身份验证， 但是当我查看此存储库的 git 提交历史记录时，我发现该提交已 由用户“root”创建。

我查看了 git-cvsserver 的源代码 (http://git.kernel.org/?p=git​​/git.git;a=blob;f=git-cvsserver.perl）并且似乎使用了CVS登录 仅用于身份验证，不用于实际提交。 SQLite 数据库中的记录也包含“root”用户名，而不是“foo”

您知道如何将 CVS 登录传播到 git 用户名吗？

git 邮件列表中的外部引用： http://thread.gmane.org/gmane .comp.version-control.git/169182

Answer 1

我对此没有具体的经验，但 git-cvsserver 几乎肯定会调用 git-commit 来完成实际工作。您可以通过设置环境变量（例如 GIT_COMMITTER_EMAIL 和 GIT_AUTHOR_EMAIL）（也是 ..._NAME 和 ..._DATE 和 ..._IDENT）。如果您有可用的身份验证信息，您只需在实际提交之前将其设置在 $ENV 中即可。如果 git-cvsserver 没有清理其环境，您实际上可以在调用它之前从包装器中的身份验证信息中设置这些环境（只是以防任何提交）。

Answer 2

在传播登录之前，如 Ben Jackson 的 answer，使用 GIT_COMMITTER_NAME/EMAIL 环境变量，确保身份验证步骤正确运行。

在 Git 2.34（2021 年第 4 季度）之前，“git cvsserver “^(man) 其身份验证代码中存在一个长期存在的错误，该错误最终已得到纠正（目前尚不清楚，但如果有人认真使用它，则是一个单独的问题）。

请参阅 提交 4b81f69、提交 bffcb4d, Carlo Marcelo Arenas Belón (carenas).
^{（由 Junio C Hamano -- gitster -- 合并于 提交 1030dae，2021 年 10 月 3 日）}

git-cvsserver：正确使用 crypt比较密码哈希

^{签字人：卡洛·马塞洛·阿里纳斯·贝隆}

c057bad ("git-cvsserver: 使用密码文件 cvsserver pserver", 2010-05-15, Git v1.7.2-rc0 -- 合并）为 git cvsserver 添加了一种方法^(man)提供经过身份验证的 pserver 帐户，无需明文密码，但使用用户名而不是密码来调用 crypt(3)。

更正该问题，并确保文档正确指示如何获取可用于填充此配置的散列密码，以及更正用于测试的散列。

此更改将要求此功能的任何用户更新其配置中的哈希值，但具有使用比 cvs 使用的更相似格式的优点，可能还可以简化任何迁移。

git cvsserver 现在包含在其 手册页：

文件，但只能使用-d选项（或-B，如果您的系统支持）。

git cvsserver 现在包含在其 手册页：

最好使用管理密码哈希的系统特定实用程序
在您的平台中创建（例如 Linux 中的 mkpasswd、OpenBSD 中的 encrypt 或
pwhash（NetBSD 中））并将其粘贴到正确的位置。

---

2023年：警告，不再使用crypt(3)，Git 2.44（2024年第一季度）对其进行了适配。

请参阅 提交 0856f13、提交 5d70afa, 提交7d05974（2023 年 11 月 10 日），作者：Patrick Steinhardt (pks-t)< /a>.
^（由 Junio C Hamano -- gitster -- 合并于 提交 0946acf，2023 年 12 月 9 日）

t/lib-httpd：停止使用用于身份验证的旧版crypt(3)

^{签字人：Patrick Steinhardt}

为我们的测试设置 httpd 时，我们还安装了包含测试用户凭据的 passwd 和 proxy-passwd 文件。
这些凭据当前使用 crypt(3) 作为密码加密架构。

现在可以认为该架构已弃用，因为它不再安全。
引用 Apache httpd 的文档：

<块引用>

仅限 Unix。
使用传统的 Unix crypt(3) 函数
随机生成的 32 位盐（仅使用 12 位）和前 8 位
密码的字符。不安全。

这开始在现代 Linux 发行版中引起问题。

glibc 已弃用其用于提供 crypt(3) 的 libcrypt 库，转而使用 libxcrypt 库。
这个较新的替换提供了一个编译时开关来禁用不安全的密码加密模式，这会导致 crypt(3) 始终返回 EINVAL。
最终结果是，在使用 libxcrypt 且没有这些不安全加密模式的发行版上，执行身份验证的 httpd 测试将​​失败。

重新生成 passwd 文件以改为使用默认密码加密架构，即 md5。
虽然基于 MD5 的加密模式应该比其他任何模式都更安全，这感觉有点有趣，但它是当前的默认设置并且受到所有平台的支持。
此外，考虑到这些文件仅用于测试目的，这实际上并不重要。