repositorio - No se pueden crear contraseñas de la tienda SVN, aunque la configuración está configurada para permitirlo

desvincular carpeta tortoise svn

Question

Hice todo lo que dice el libro, es decir, eliminé los archivos de autenticación de .subversion / auth, y establecí explícitamente los parámetros de configuración relevantes en ''sí'' , aunque esto es un valor predeterminado, y los comandos SVN del shell piden una contraseña cada vez. El repositorio está en cvsdude.com, y el cliente es Linux. También utilizo el complemento Subclipse que almacena en caché la contraseña OK.

Recuerdo vagamente que cuando comencé a trabajar con él, el comando me preguntó de forma interactiva si quería guardar una contraseña clara y dije que no. ¿Se puede almacenar esta opción en algún lugar y tener prioridad sobre la configuración?

Answer 1

Con las versiones recientes de Subversion (~ 1.8) puede configurar el almacenamiento en caché de contraseñas a través de $HOME/.subversion/servers :

[global]
store-passwords = yes
store-plaintext-passwords = yes

Pero dependiendo de su sistema, esto puede no ser suficiente. Si no lo está, asegúrese de que $HOME/.subversion/config contenga:

[auth]
password-stores =

Lo que significa que los almacenes de contraseñas variables se establecen explícitamente en la cadena vacía (en segundo plano, svn ahora contiene soporte para algunas herramientas del agente de claves, y la interfaz con las configuradas por defecto puede ser frágil, lo que hace que se ignoren las opciones anteriores) y comportamiento no caché).

Cuando se usa svn por primera vez, la jerarquía $HOME/.subversion se crea después de la primera operación svn, por ejemplo, cuando se realiza la primera verificación. Subversion crea entonces los archivos mencionados y los llena con las opciones más importantes, comentadas, incluida alguna documentación.

Por lo tanto, también tiene sentido alejar un antiguo directorio de $HOME/.subversion para tener un punto de inicio bien definido.

Otro inconveniente son los permisos, es decir, los archivos que no se pueden leer en $HOME/.subversion , pero este no suele ser el problema, ya que svn crea, se ocupa de los permisos correctos (por ejemplo, el directorio auth solo puede leerlo el usuario entonces, no por el grupo / todos, independientemente de la umask configurada).

Answer 2

Creo que he encontrado una sugerencia útil aquí: http://svn.haxx.se/users/archive-2013-07/0094.shtml

Como entendí, el cliente olvidó verificar si un "gpg-agent" se está ejecutando actualmente.

Se está insertando el "passtype" = "gpg-agent" en los ~/.subversion/auth/svn.simple/ -cache-de forma predeterminada.

¡Eso es un error!

Como solución (y para evitar alterar la contraseña-caché en ~. / Subversion / auth / svn.simple / a mano) elimine estos archivos (pero haga una copia para guardar).

Agregue la línea, en ~/.subversion/config ([auth] -section):

password-stores=

(CONSIDERE: ¡el valor vacío! Esto evita que el cliente elija cualquier cosa incorrecta y asuma "simple".)

Ahora, por ejemplo, pruebe a:

svn up

Subversion ahora te advertirá que guardes contraseñas simples.

Si no tienes ningún problema con eso, escribe "sí" y todo está bien otra vez.

Después de eso, Subversion ha creado un archivo de caché para un servidor en particular, y puede eliminar la entrada "almacenes de contraseñas" nuevamente.

Answer 3

Eliminar archivos del siguiente directorio:

Para ventanas:

Por ejemplo:

C: / Users / abcd.xyz / AppData / Roaming / Subversion / auth / svn.simple

abcd.xyz -> nombre de usuario

Nota: Eliminar todos los archivos. Estos archivos contienen metadatos sobre la comprobación. La próxima vez que almacene su contraseña, creará automáticamente un archivo aquí.

Elimine el archivo .keyring de su instalación de STS / Eclipse . Detener Eclipse y eliminar el archivo.

Por ejemplo:

D: / Executables / New STS / STS-3.5.0-e4.3.2-win64 / configuration / org.eclipse.core.runtime ->. Keyring

Answer 4

Elimine la contraseña almacenada anterior como rm ~ / .subversion / auth / svn.simple / * . He intentado todas las sugerencias y esto es lo que funcionó para mí.

Answer 5

En Windows con slikSVN, tenía el mismo problema, pero solo con uno de los proyectos, así que ingresé a% AppData% / Roaming / Subversion / auth / svn.simple y eliminé el archivo que contenía la información del proyecto.

El siguiente comando SVN que escribí solicitó la contraseña y volvió a crear el archivo y ahora está funcionando muy bien.

Tal vez el hecho de que cambié la configuración y los archivos de los servidores también ayudara, pero no funcionó hasta que eliminé ese archivo (y también funcionó con la configuración anterior hasta que hubo un problema de contraseña en el servidor y el administrador restableció los permisos).

Answer 6

Experimenté tales problemas después de un cambio de contraseña y lo curé eliminando la configuración de SVN (y, por lo tanto, volviéndolo a crear desde cero).

Answer 7

Gracias a sus comentarios, encontré el problema: es la configuración en el archivo de servidores (no almacenar contraseñas simples). Me pregunto por qué existe esta redundancia con la sección [auth] del archivo de configuración. El libro de SVN tampoco menciona esto cuando se habla de almacenar contraseñas.

Answer 8

Me encontré con este mismo problema, y ​​creo que también puse todas las configuraciones apropiadas en .subversion / servers y .subversion / config, intenté eliminar .subversion / auth, etc., pero fue en vano.

Terminé guardando las credenciales moviendo el directorio .subversion (o eliminándolo también funcionaría) y ejecutando svn co. Recibí el siguiente mensaje:

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <http://sweeney:80> Subversion repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the ''store-plaintext-passwords'' option to either ''yes'' or ''no'' in
''/home/davids/.subversion/servers''.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? 

Escribí que sí, y luego recibí el mismo mensaje. Obstinadamente, escribí sí otra vez. Ahora mi contraseña parece estar guardada.

Algo sorprendente, al ver las confusiones en la subdivisión, ninguno de los ajustes está sin comentar; Todos están configurados con los valores predeterminados, por lo que imagino que tendría que responder a esta advertencia dos veces para guardar una contraseña para un servidor diferente en el futuro.

Espero que esto ayude.

Answer 9

Me gustaría enviar una respuesta detallada en caso de que ayude a alguien en el futuro.

Subversion 1.6 y versiones posteriores almacenarán en caché su nombre de usuario y contraseña de forma predeterminada, sin embargo, no almacenará las contraseñas en texto sin formato a menos que lo permita explícitamente a través de la línea de comandos o cambiando la configuración de Subversion.

Si sacó una copia de trabajo usando las opciones --usuario y - contraseña, verá el siguiente mensaje:

-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

<https://subversion.assembla.com:443> Assembla Restricted Area

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the ''store-plaintext-passwords'' option to either ''yes'' or ''no'' in
''~/.subversion/servers''.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? 

Entonces, como se menciona en el mensaje, subversion solo guardará la contraseña sin cifrar si ingresa ''sí''. Si lo hace, entonces no debería necesitar agregar las opciones --username o --password cuando ejecute los comandos svn en el futuro.

Sin embargo, si prefiere no ver este aviso, puede cambiar la configuración global de su cliente de Subversion cambiando el archivo de configuración llamado "servidor" en su máquina local. Se almacena aquí:

~/.subversion/server

Deberá agregar las siguientes líneas al archivo "servidor":

[global]
store-plaintext-passwords = yes

Con este cambio, solo necesita ejecutar un comando svn usando las opciones --username y --password una vez. Luego, Subversion guardará automáticamente sus credenciales sin el aviso anterior.

Para obtener más información sobre cómo deshabilitar esta advertencia sobre el almacenamiento en caché de contraseñas en texto sin formato, consulte la publicación del blog de mejoras de seguridad de Subversion 1.6 .

Answer 10

Necesitaba hacer cambios en el archivo del servidor para que esto me funcionara

# Password / passphrase caching parameters:
store-passwords = yes
store-plaintext-passwords = yes

Answer 11

Por alguna extraña razón, mi carpeta .subversion no era de mi propiedad y SVN no guardaría los certificados de contraseñas.

Acabo de hacer un sudo chown -R me ~/.subversion y ahora todo funciona!

Answer 12

Por lo que leí en las respuestas anteriores, ninguno de estos funcionó. Lo que encontré que funciona para mí podría ser una combinación de cosas o este último paso, que es abrir la aplicación de llavero, busque la clave en cuestión.

Haga clic derecho y vaya a "obtener información". Haga clic en la sección de control de acceso en la parte superior. Luego haga clic en "Permitir que todas las aplicaciones accedan a este elemento". Aunque esto podría hacer algo involuntario.

Answer 13

Puedes usar el anillo de llaves de gnome incluso sin X inited. Deberías correr

export `gnome-keyring-daemon`

en el inicio de sesión y

kill $GNOME_KEYRING_PID

antes de cerrar sesión.

Luego puedes usar la utilidad de línea de comandos keyring_tool .

Answer 14

Si está intentando restablecer la autenticación en una copia de trabajo existente, le recomiendo que revise una copia nueva después de hacer todos los cambios anteriores. Esto fue lo único que funcionó para mí cuando intentaba lanzar el proyecto con el complemento de liberación de maven (que utiliza las credenciales svn almacenadas para confirmar automáticamente sus etiquetas, etc.)

Answer 15

Tenga en cuenta que existe un comportamiento diferente relacionado con el almacenamiento de la contraseña entre un svn co / up y un svn log!

Intenté todos los consejos anteriores y siempre intenté verificar con ''svn log'': el comando svn siempre me pedía una y otra vez la contraseña, sin importar si Store-plaintext-passwords estaba configurado correctamente para preguntar o sí. Pero cuando hice una nueva compra o actualización, de repente tuve el comportamiento correcto y mi contraseña se guardó

Supongo que esto es un error de Subversion para tener un manejo diferente del almacenamiento de contraseñas para los diferentes comandos, al menos no leí nada sobre eso antes.

Answer 16

Una solución que funcionó para mí (incluso no es la mejor solución, al menos me rescató), es otorgar a mi usuario local todos los permisos para el directorio y subdirectorios ~ / .subversion. Entonces podría realizar operaciones en subversión rápidamente sin un nombre de usuario y contraseña rápidos.