Sinopse
As tarefas necessárias para instalar o svn com suporte ao chaveiro e instalar o aplicativo Collabnet keyring_tool já foram realizadas para nossos servidores Linux.
1) Configure o cliente SVN para usar o chaveiro:
1.1) Editar ~ / .subversion / config
[auth]
password-stores = gnome-keyring
1.2) Editar ~ / .subversion / servers
[global]
store-passwords = yes
store-plaintext-passwords = no
2) Crie um chaveiro para sua senha. Você será solicitado a criar uma nova senha para desbloquear o chaveiro; pode ser o que você desejar:
keyring_tool --create=svn
3) Defina o novo chaveiro como padrão:
keyring_tool --setdef=svn
4) Em .bash_profile ou .bash_login (assumindo que você esteja usando o bash como seu terminal)
if [ -e /usr/bin/gnome-keyring-daemon ]; then
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
# Create dbus transport link for SVN to talk to the keyring.
eval `dbus-launch --sh-syntax`
# Start the keyring daemon.
# The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
# env values echoed out at startup.
export `/usr/bin/gnome-keyring-daemon`
fi
fi
5) Em .bash_logout
# Kill the message bus established for SVN / Keyring communication
if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1
fi
# Kill the Gnome Keyring Daemon prior to logout.
if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
kill $GNOME_KEYRING_PID > /dev/null 2>&1
fi
fundo
Encontrei um problema semelhante ao tentar estabelecer uma maneira livre de problemas para garantir o acesso do usuário autorizado a determinados repositórios SVN no trabalho. Basicamente, tivemos que forçar a verificação de credenciais toda vez que um usuário acessa o servidor, para que mesmo o comando svn update exija autenticação. O armazenamento de senhas em texto sem formatação ficou claro, então, com uma pequena pesquisa, deparei-me com o gnome-keyring como uma maneira de contornar nossa base de usuários com solicitações de autenticação constantes e ainda manter usuários não autorizados fora dos repositórios que eles não deveriam ter acesso para visualizar.
Grande parte do nosso dia-a-dia é feita através de túneis ssh em um servidor RedHat sem suporte ao X, então tive que encontrar uma maneira de contornar o suporte ao X11. Depois de algumas pesquisas, consegui encontrar a maneira de contornar isso aqui:
Material de origem
http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh -sessão
A chave aqui é usar o Collabnet keyring_tool para criar um chaveiro sem o cliente gnome-keyring-manager e estabelecer o dbus-launch você mesmo, em vez de deixar o SVN cuidar da configuração. O SVN usa o DBUS para conectar-se ao gnome-keyring-daemon e afetar a autenticação geral. Ao iniciar e derrubar manualmente a sessão do dbus com a sintaxe -sh, você evita tentar se conectar a um cliente X na inicialização do dbus. Se você acabou de iniciar o gnome-keyring-daemon e tentar usar o SVN, ele ainda solicitará sua senha do chaveiro, mas também solicitará suas credenciais SVN. O dbus falhará quando o SVN tentar iniciá-lo devido à falta de um cliente X; aparentemente o SVN não usa nenhum sinalizador especial ao iniciar o dbus.
--login
É bastante útil, embora eu com certeza não queira manter minha senha desmontada em um script ou colocá-la em uma linha de comando. a leitura no modo não especificado de um script (em linguagem não shell) que passa essa entrada para o daemon gerado provavelmente seria uma boa maneira de fazer isso. Eu só deveria ter que iniciar esse processo uma vez por inicialização, por isso faz sentido digitar a senha; Eu só preciso fazer isso na linha de comando, e não na caixa de diálogo GTK.