Si estoy almacenando mi código fuente en SVN en una empresa de alojamiento compartido, ¿sería posible encriptar el contenido de modo que INCLUSO si alguien tiene acceso al repositorio, no puedan ver la fuente a la vista?¿Es posible encriptar el contenido almacenado en SVN?
¿Hay un complemento para esto? De lo contrario, ¡me imagino que sería una locura implementarlo!
La respuesta correcta es ya sea:
Si la principal preocupación es tener una copia de seguridad segura fuera del sitio, aloje el repositorio usted mismo y use algún lugar como rsync.net para manejar la copia de seguridad (son SOX/HIPAA en conformidad). Un trabajo cron que sincronice todo cada 15 minutos debería ser suficiente. El trabajo cron puede encriptar su copia de seguridad antes de presionarlo. Simplemente no pierdas las llaves/contraseñas.
De esta forma, Subversion no necesita saber nada acerca de su esquema de cifrado, y puede realizar su trabajo sin tener que preocuparse por la paranoia que obstaculiza la productividad.
Adenda:
Puesto que usted está haciendo el alojamiento compartido y servidores compartidos no vale nada: Obtener un dedicado anfitrión de control de origen. No siempre utilice un host compartido para el control de código fuente. Los hosts compartidos son conocidos por perder datos y realizar afirmaciones falsas sobre la seguridad de los datos y las copias de seguridad.Buenos ejemplos de hosts de control de fuente dedicados: CVSDude, Beanstalk, GitHub
+1 - Si no confías en tu host, ** ¡encuentra uno nuevo! ** –
También agregaré que uno de los buenos efectos secundarios del control de versión distribuida es que cada clon del repositorio esencialmente * es * Una copia de seguridad. Además, confío absolutamente en GitHub con prácticamente todo lo que escribo. Ver también: http://svnhub.com/ –
¿Github permite repositorios encriptados? –
La publicación de Mathew es para un sistema de archivos encriptados que el proveedor de hosting debería proporcionar. Esa es probablemente la única manera fácil de hacerlo.
No solo se trata de eso: también está almacenando blobs cifrados en el repositorio, perdiendo todo el seguimiento de la versión útil en el proceso. –
Urgh tienes razón, no había leído tanto detalle. –
El plugin que le gustaría tener tendría que estar en el lado del cliente (Obviamente, si no confía en las personas que tienen acceso al repositorio alojado). Cualquier algoritmo criptográfico fuerte genera grandes variaciones en la salida de una entrada muy similar (debido a su alta entropía).
Esto significa que incluso si usted tiene una solución:
cifrado débil (mangling el juego de caracteres, por ejemplo, que haría que las diferenciaciones utilizable de nuevo) no es seguro, especialmente con el código fuente, donde los apoyos y soportes y desde allí bucles y cualesquiera otras cartas pueden ser decodificados de forma extremadamente rápida.
Espero que esto demuestre que ir de esta manera no conduce a ninguna posible solución práctica. Tal vez me estoy perdiendo algo. ¡Espero leer comentarios interesantes sobre mi respuesta! :-)
Es viejo pero encuentro otra solución para esto y puede ayudar a otros.
Hoy puede obtener algunos Servidores Virtuales Virtuales (VPS) muy baratos. ($ 5/mes)
¿Por qué VPS? ¡Puedes instalar lo que quieras!
puedo configurar todo con este artículo: http://cinserely.blogspot.com.br/2010/10/creating-encrypted-subversion.html
Cómo (4.) http://tortoisesvn.net/sasl_howto.html
Debería ser posible (en algunos sistemas de control de revisiones, dependiendo de cómo funcionan internamente): Si la revisión el sistema de control almacena los deltas (no las revisiones), y no te importa filtrar cuántas revisiones hay. Luego podría encriptar los deltas y luego verificarlos en otro repositorio. Ahora puedo ver la historia (tal vez registrar comentarios, dependiendo de la política), sin la clave. Pero necesitas la clave para ver algo más. Diffs funcionará bien, y el tamaño del repositorio no se verá afectado adversamente, ya que la compresión del repositorio aún funciona como se hace localmente, antes de la encriptación. –