我的 Subversion 服务器仅提供通过 HTTPS 的访问；我们已放弃对 svn+ssh 的支持，因为我们想避免在该机器上创建仅用于 SVN 访问的系统用户。现在，我正尝试为用户提供一种方法来暂时缓存他们的密码，而不会将其以未加密的形式存储在文件系统上。
对于 Gnome 或 KDE 用户来说这不是问题，因为他们可以分别使用 gnome-keyring 和 kwallet。如果我没记错的话，TortoiseSVN 也有类似的缓存机制。但是对于非 GUI 系统上的用户怎么办呢？
一些背景信息：在本例中，我们有一个开发/测试服务器，其中一个项目已签出到 Apache htdocs 目录中。该项目的开发已接近完成，并且只在此服务器上直接执行了少量的文本/布局更改。尽管如此，这些更改仍应签入存储库。此系统上没有 kwallet 和 gnome-keyring，ssh-agent 也无能为力，因为存储库是通过 https 而不是 svn+ssh 访问的。
据我所知，他们只能选择在每次与 SVN 服务器通信时输入密码，或者以不安全的方式存储密码。
有没有办法在非 GUI 环境中获得类似 gnome-keyring 和 kwallet 提供的东西？
答案1
你不能。
HTTPS 不支持任何类型的单向密码哈希处理。在此过程中的某个时刻，您需要可用的纯文本密码。到目前为止，可能可以对其进行加密，但是考虑到您还需要服务器上的解密密钥，因此意义不大。
即使 HTTPS 支持单向密码散列，您也无法这样做（它需要对重放攻击有一定的保护措施，否则您的密码散列就变成了密码！）
这不是一个真正的解决方案，但切换到分布式的东西，比如 Git，可以很好地解决这个问题。您可以让用户将 SSH 代理转发配置到他们要连接的机器，然后身份验证将基于此。
答案2
不确定 IT 人员对我们的 SVN 服务器做了什么导致了这种情况，但我厌倦了 GUI 密码提示，因此我调整了~/.subversion/config文件以删除 [gui] kwallet，并且仅使用文本模式提示：
password-stores = gnome-keyring
但即使这样仍然有点烦人，所以我在源代码树中做了几次：
vi +/http .svn/entries
并将其更改http:为https:几次，然后我就不再被提示了。
奇怪的是，我不需要到处都改变它...或者可能在任何地方...在某个时候，守护进程死了或者发送了SIGHUP或者其他什么...我注意到这个目录下的一个文件被更新了：
~/.subversion/auth/svn.simple/
看起来不错。啊，黑客式的解决方法。