暗号化されていない形式で保存せずに、Subversionパスワードをサーバーにキャッシュするにはどうすればよいですか？
私のSubversionサーバーはHTTPS経由のアクセスのみを提供します。 svn + sshのサポートは、SVNアクセスのためだけにそのマシンでシステムユーザーを作成することを避けたかったため、削除されました。現在、ユーザーがパスワードを暗号化されていない形式でファイルシステムに保存したままにせずに、しばらくの間パスワードをキャッシュする方法を提供しようとしています。
GnomeまたはKDEユーザーは、それぞれgnome-keyringおよびkwalletを使用できるため、これは問題ありません。 IIRC、TortoiseSVNにも同様のキャッシュメカニズムがあります。しかし、非GUIシステムのユーザーはどうでしょうか。
いくつかのコンテキスト：この場合、1つのプロジェクトがApachehtdocsディレクトリにチェックアウトされている開発/テストサーバーがあります。このプロジェクトの開発はほぼ完了しており、テキスト/レイアウトのわずかな変更のみがこのサーバーで直接実行されます。それでも、変更はリポジトリにチェックインする必要があります。このシステムにはkwalletもgnome-keyringもありません。また、リポジトリはsvn + sshではなくhttps経由でアクセスされるため、ssh-agentは役に立ちません。
私の知る限り、SVNサーバーと通信するたびにパスワードを入力するか、安全でない方法でパスワードを保存するかを選択できます。
GUI以外の環境でgnome-keyringやkwalletが提供するようなものを入手する方法はありますか？
いいえ、あなたがすることはできません。
HTTPSは、パスワードの一方向ハッシュをサポートしていません。プロセスのある時点で、プレーンテキストのパスワードを使用できるようにする必要があります。この時点までは暗号化できる可能性がありますが、サーバーにも復号化キーが必要になることを考えると、ほとんど意味がありません。
HTTPSがパスワードの一方向ハッシュをサポートしていても、これを行うことはできません（リプレイ攻撃に対する保護が必要です。そうしないと、パスワードハッシュがパスワードになります！）
これは実際の解決策ではありませんが、Gitなどの分散型のものに切り替えると、この問題はうまく解決されます。ユーザーに、接続先のマシンへのSSHエージェント転送を構成させ、認証はそれに基づいて行います。
IT担当者がこれを引き起こすためにSVNサーバーに対して何をしたのかわからないが、GUIパスワードプロンプトにうんざりしたので、~/.Subversion/configファイルを微調整して[gui] kwalletを削除し、テキストモードのプロンプトのみを使用しました。
password-stores = gnome-keyring
しかし、それでもやや面倒だったので、ソースツリーでこれを数回行いました。
vi +/http .svn/entries
http:をhttps:に数回変更したところ、プロンプトが表示されなくなりました。
奇妙なことに、どこでも変更する必要はありませんでした...またはおそらくどこでも...ある時点で、デーモンが停止したか、SIGHUPが送信されました...このディレクトリの下のファイルの1つが更新されていることに気付きました：
~/.Subversion/auth/svn.simple/
どのように良いようです。ああ、ハックの素晴らしい回避策。