que - git remote

git encriptar/desencriptar archivos del repositorio remoto mientras se presiona/jala

Question

¿Es posible cifrar archivos automáticamente mediante ''git push'' antes de transferirlos a un repositorio remoto? Y decodificarlos automáticamente mientras ''git pull''.

Es decir, si tengo algún servidor remoto con acceso compartido con el repositorio de git allí, y no quiero que nuestro proyecto sea robado sin permiso ... ¿Tal vez haya algunos git-hooks especiales antes del push y after pull?

Answer 1

Cómo proteger activos remotos públicos y privados usando git-crypt .

• Transparente para todos los clientes y servicios de GIT (por ejemplo, GitHub, BitBucket, etc.).
• Compatibilidad con Linux, OSX y Windows.
• Encriptación del nivel de activos (ver la respuesta de VonC ).
• AES-256 .
  
  

Crea tu clave privada de 256 bits (RETENCIÓN Y PROTECCIÓN DE ESTA CLAVE)

sudo apt install git-crypt
mkdir key; cd key;
git init; git-crypt init
git-crypt export-key ~/crypt.key

Commit & Push un archivo llamado .gitattributes al directorio raíz de cada repositorio.
Debe contener un patrón de activo por archivo, directorio o tipo que desee encriptar:

docs/doc.txt filter=git-crypt diff=git-crypt
js/** filter=git-crypt diff=git-crypt
*.java filter=git-crypt diff=git-crypt
src/cpp/*.h filter=git-crypt diff=git-crypt

Cifrar activos en cada repositorio:

cd repo-root-directory
git-crypt unlock ~/crypt.key
git-crypt status -f
Commit&Push (from command line or git client)

Continúa tu flujo de trabajo de git como de costumbre.

• Ejecute git-crypt unlock ~/crypt.key una vez en cualquier clon nuevo de estos git-crypt unlock ~/crypt.key seguros.
• Es posible que desee purgar historiales de confirmación descifrados antiguos en todas las ramas y etiquetas.
• Si usa un cliente de git, debe ser totalmente compatible con los filtros de git y diffs.
  
  
  

Answer 2

Hay dos maneras de hacer esto.

Una es usar un proyecto como git-crypt, http://www.agwa.name/projects/git-crypt/ , que agrega elementos para el proceso de extracción e inserción, o configura los filtros manualmente como se describe aquí https://gist.github.com/shadowhand/873637

Otra forma si está trabajando en un entorno Linux es usar ecryptfs. Para este escenario, en la base de su directorio de proyecto podría, por ejemplo, crear dos directorios

project/encrypted_src
project/src

Luego, desde la raíz del directorio del proyecto, montarías usando el comando

sudo mount -t ecryptfs encrypted_src src

ingresar una contraseña y aceptar los valores predeterminados cuando se le solicite. En este punto, los archivos colocados en src / se cifrarán en encrypted_src / sobre la marcha. Cuando termines solo

sudo umount src

y solo quedan los archivos encriptados. Básicamente, los archivos se envían y se envían desde encrypted_src / y se editan en src. Siempre que todos utilicen la misma contraseña (o que se monte con la misma clave), el repositorio se puede compartir entre desarrolladores. También puedes ser más elegante. Puede encriptar los nombres de los archivos, así como solo los contenidos de los archivos, o encriptar diferentes carpetas en un repositorio con diferentes frases de paso o claves. La última característica es agradable si tiene archivos de configuración con información de acceso confidencial que los grupos individuales (desarrollo, prueba, producción) desearán mantener de forma privada.

Dicho esto, sin embargo, ten en cuenta que una vez que comienzas a encriptar cosas. Pierdes muchas de las ventajas del control de código fuente, como poder ver diferencias entre varias confirmaciones. Si tienes un proyecto de cualquier tamaño, la capacidad de revisar confirmaciones será invaluable. Si esperas errores, en algún momento u otro, la capacidad de analizar y encontrar su punto de introducción mediante el seguimiento a través del historial de compromisos también será invaluable. Primero, asegure su servidor y luego use el cifrado solo donde tenga sentido para proteger la información confidencial en el control de la fuente. Solo mis 2 centavos.

Answer 3

Hay ganchos Tahoe-LAFS provistos por git-annex , que sin duda pueden ser más complicados de lo que necesita.

Answer 4

Puede echar un vistazo a este proyecto: https://github.com/shadowhand/git-encrypt

ACTUALIZACIÓN : Este proyecto anterior está en desuso y recomienda usar git-crypt

Answer 5

Si y no.

Podría intentar depender del enganche, pero eso supone que están instalados en ubicaciones remotas, y eso no siempre es confiable.

Otra forma de lograr casi el mismo efecto sería usar un controlador de filtro de atributo de limpieza / borrado , pero no para un repositorio completo .

^{(Fuente: libro de Pro Git : Personalización de Git - Atributos de Git )}

De esta forma, la secuencia de comandos de borrado puede decodificar los archivos, mientras que la secuencia de comandos limpia los codificaría.
Una vez más, eso podría funcionar para algunos archivos confidenciales, no para un repositorio completo .

Por supuesto, esos scripts no estarían en el repositorio en sí, y serían administrados / comunicados de otra manera.

Como señala Alkaline en los comentarios , esa idea no escala para un repositorio, como comenta el principal mantenedor de git Junio ​​C. Hamano en 2009 :

Como la única razón de ser de diff.textconv es permitir conversiones potencialmente con pérdidas (por ejemplo, msword-to-text) aplicadas al par de contenido de preimagen y postimagen (que se supone que son "limpias") antes de dar una diferencia textual consumo humano.

La configuración anterior puede parecer que funciona, pero si realmente desea un repositorio encriptado, debe usar un sistema de archivos encriptado.
Eso daría un beneficio adicional de que el árbol de trabajo asociado con su repositorio también estaría encriptado .

Aunque no se amplía a un repositorio completo, la idea se implementó (3 años más tarde en 2013) con git-crypt , como se detalla en la answer Dominic Cerisano .
git-crypt usa un controlador de filtro de contenido (implementado en cpp, con commands.cpp configurando sus .gitattributes con la smudge correspondiente y clean los comandos de filtro).
Como cualquier controlador de filtro de contenido, puede limitar la aplicación de git-crypt al conjunto de archivos que desee, en el mismo archivo .gitattributes :

secretfile filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt

Como se menciona en el README :

git-crypt basa en filtros git, que no fueron diseñados con encriptación en mente.

Como tal, git-crypt no es la mejor herramienta para encriptar la mayoría o la totalidad de los archivos en un repositorio.
Donde realmente brilla git-crypt es donde la mayoría de su repositorio es público, pero tiene algunos archivos (tal vez claves privadas llamadas *.key , o un archivo con credenciales de API) que necesita encriptar.

Para encriptar un repositorio completo, considere usar un sistema como git-remote-gcrypt .

(ver más en git-remote-gcrypt , de Sean Whitton )