spwhitton/git-remote-gcryptAsistente remoto de Git para operaciones push/pull cifradas con PGP de forma transparente, compatible con backends local, rsync, SFTP y git, con claves de participante configurables.
:Sección del manual: 1
git-remote-gcrypt es un ayudante de remoto git para enviar y recibir desde
repositorios cifrados con GnuPG, utilizando un formato personalizado. Este
ayudante de remoto maneja URIs con prefijo gcrypt::.
Los backends compatibles son local, rsync:// y sftp://, donde el
repositorio se almacena como un conjunto de archivos, o cualquier <giturl>
donde gcrypt almacenará la misma representación en un repositorio git,
puenteado a través de un transporte git arbitrario. Prefiera local o rsync://
si puede usar alguno de ellos; consulte "Rendimiento" más abajo para discusión.
También hay un backend rclone:// experimental solo para primeros adoptantes
(ya está advertido).
El objetivo es proporcionar almacenamiento git confidencial y autenticado y colaboración utilizando servicios o alojamientos de archivos no confiables típicos.
Instalación ............
utilice el gestor de paquetes de su distribución GNU/Linux -- Debian, Ubuntu, Fedora, Arch y algunas distros más pequeñas tienen paquetes conocidos
ejecute el script install.sh proporcionado en otros sistemas
Inicio rápido ..........
Cree un remoto cifrado enviando a él::
git remote add cryptremote gcrypt::rsync://example.com/repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch] master -> master
Se admiten las siguientes variables de git-config(1):
remote.<name>.gcrypt-participants
..
gcrypt.participants
Lista separada por espacios de identificadores de clave GPG. El remoto se cifra
para estos participantes y solo se aceptan firmas de ellos.
gpg -k lista todas las claves públicas que conoce.
Si no se establece esta opción, se cifra para su clave predeterminada y se acepta
cualquier firma válida. Este comportamiento también se puede solicitar explícitamente
estableciendo participantes en ``simple``.
La configuración ``gcrypt-participants`` en el remoto tiene prioridad
sobre la variable del repositorio ``gcrypt.participants``.
remote.<name>.gcrypt-publish-participants
..
gcrypt.publish-participants
Por defecto, los ids de las claves gpg de los participantes se ocultan
cifrando usando gpg -R. Establecer esta opción a true deshabilita
esa medida de seguridad.
El problema de usar ``gpg -R`` es que para descifrar, gpg prueba cada
clave secreta disponible por turno hasta encontrar una clave utilizable.
Esto puede resultar en solicitudes de frase de contraseña innecesarias.
gcrypt.gpg-args
El contenido de esta configuración se pasa como argumentos a gpg.
Ej.: --use-agent.
remote.<name>.gcrypt-signingkey
..
user.signingkey
(Este último de la configuración regular de git) La clave a usar para firmar.
Debe establecer user.signingkey si su clave de firma predeterminada no está
en la lista de participantes. Puede usar la versión por remoto
para firmar diferentes remotos usando diferentes claves.
remote.<name>.gcrypt-rsync-put-flags
..
gcrypt.rsync-put-flags
Banderas a pasar a rsync al subir a un remoto usando el
backend rsync://. Si las banderas se establecen para un remoto específico,
las banderas globales, si también están establecidas, no se aplicarán para ese remoto.
remote.<name>.gcrypt-require-explicit-force-push
..
gcrypt.require-explicit-force-push
Un error de larga data es que cada git push efectivamente tiene un --force.
Si esta bandera se establece en ``true``, git-remote-gcrypt se negará a hacer push,
a menos que se pase ``--force``, o las refspecs tengan prefijo ``+``.
Hay una solución potencial aquí: https://bugs.debian.org/877464#32
GCRYPT_FULL_REPACK Cuando se establece (a cualquier cosa que no sea la cadena vacía), esta variable de entorno fuerza un reempaquetado completo al hacer push.
Cómo configurar un remoto para dos participantes::
git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master
Cómo usar un backend git::
# note que el repositorio git de destino ya debe existir y su
# rama `next` será sobrescrita.
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master
El fragmento de URL (#next aquí) indica qué rama del backend se utiliza.
Colaboración El cifrado del manifiesto se actualiza en cada push para coincidir con la configuración de participantes. Cada usuario que hace push debe tener las claves públicas de todos los colaboradores y la configuración de participantes correcta.
Dependencias
rsync, curl y rclone para los remotos rsync:, sftp: y
rclone: respectivamente. El ejecutable principal requiere un shell compatible
con POSIX que soporte local.
GNU Privacy Guard
Se admiten tanto GPG 1.4 como 2. Necesita una clave GPG personal. La configuración
de GPG se aplica a las elecciones de algoritmo para cifrado de clave pública,
cifrado simétrico y firma. Consulte man gpg para más información.
ID remoto El ID remoto no es secreto; solo asegura que dos repositorios firmados por el mismo usuario puedan distinguirse. Verá una advertencia si el ID remoto cambia, lo que solo debería suceder si el remoto fue recreado.
Rendimiento
Utilizar cualquier <giturl> o una URI sftp:// requiere
subir todo el historial del repositorio con cada push. Esto
significa que los pushes de su repositorio se vuelven más lentos con el tiempo,
a medida que su historial git se alarga, y fácilmente puede llegar al
punto en que el uso continuado de git-remote-gcrypt sea impracticable.
Por lo tanto, debe usar estos backends solo cuando sepa que su
repositorio nunca crecerá mucho, no solo que no es grande ahora.
Esto significa que estos backends son inapropiados para la mayoría
de los repositorios, y probablemente adecuados solo para casos
inusuales, como pequeños almacenes de credenciales. Incluso entonces, use `rsync://`
si puede. Sin embargo, tenga en cuenta que `rsync://` no funcionará con un
servicio de alojamiento de repositorios como Gitolite, GitHub o GitLab.
URIs rsync
El formato de URI para el backend rsync es rsync://user@host/path,
que se traduce a la ubicación rsync user@host:/path,
accedida a través de ssh. Tenga en cuenta que la ruta es absoluta, no relativa al
directorio home. También se admite un formato de URI anterior no estándar:
rsync://user@host:path, que se traduce a la ubicación rsync
user@host:path
Backend rclone
Además de agregar el backend rclone como remoto con URI como
gcrypt::rclone://remote:subdir, debe agregar el remoto a la
configuración de rclone también. Esto se hace típicamente ejecutando
rclone config. Consulte rclone(1).
El backend rclone se considera experimental y es solo para
primeros adoptantes. Ya está advertido.
Formato del repositorio .....................
| EncSign(X): Firma y cifra para el titular de la clave GPG
| Encrypt(K,X): Cifra usando algoritmo de clave simétrica
| Hash(X): SHA-2/256
|
| B: lista de ramas
| L: lista del hash (Hi) y la clave (Ki) para cada packfile
| R: ID remoto
|
| Para escribir el repositorio:
|
| Almacene cada packfile P como Encrypt(Ki, P) → P' en el archivo Hi
| donde Ki es una nueva cadena aleatoria y Hash(P') → Hi
| Almacene en el manifiesto
|
| Para leer el repositorio:
|
| Obtenga el manifiesto, descifre y verifique usando el llavero GPG →
| Advierta si no coincide con el ID remoto visto anteriormente
| para cada en :
| Obtenga el archivo del servidor →
| Verifique que coincida con
| Descifre usando → luego abra con git
Archivo de manifiesto .....................
Ejemplo de archivo de manifiesto (con puntos suspensivos por brevedad)::
$ gpg -d 91bd0c092128cf2e60e1a608c31e92caf1f9c1595f83f2890ef17c0e4881aa0a
542051c7cd152644e4995bda63cc3ddffd635958 refs/heads/next
3c9e76484c7596eff70b21cbe58408b2774bedad refs/heads/master
pack :SHA256:f2ad50316...cd4ba67092dc4 z8YoAnFpMlW...3PkI2mND49P1qm
pack :SHA256:a6e17bb4c...426492f379584 82+k2cbiUn7...dgXfyX6wXGpvVa
keep :SHA256:f2ad50316...cd4ba67092dc4 1
repo :id:OYiSleGirtLubEVqJpFF
Cada elemento se extiende hasta la nueva línea y coincide con uno de los siguientes:
<sha-1> <gitref>
Id de objeto git y su ref
pack :<hashtype>:<hash> <key>
Hash del packfile (Hi) y clave simétrica correspondiente (Ki).
keep :<hashtype>:<hash> <generation>
Hash del packfile y su generación de reempaquetado
repo <id>
El id remoto
extn <name> ...
Campo de extensión, conservado pero no utilizado.
Para detectar si una url git es un repositorio gcrypt, use: git-remote-gcrypt --check url
El estado de salida es 0 si el repositorio existe y puede descifrarse, 1 si el repositorio
usa gcrypt pero no pudo descifrarse, y 100 si el repositorio no está cifrado
con gcrypt (o no pudo accederse).
Tenga en cuenta que esto tiene que obtener el contenido del repositorio en el repositorio git local, igual que se hace al usar un repositorio gcrypt.
Cada git push efectivamente tiene --force. Asegúrese de hacer pull antes de
push.
git-remote-gcrypt puede decidir reempaquetar el remoto sin advertencia, lo que significa que su push puede repentinamente tomar mucho más tiempo del que esperaba, ya que todo su historial tiene que ser re-subido. Este push podría fallar en un enlace deficiente.
git-remote-gcrypt puede reportar un repositorio como "no encontrado" cuando el repositorio realmente existe, pero git-remote-gcrypt está teniendo problemas de autenticación, puerto o conectividad de red.
git-remote-helpers(1), gpg(1)
El autor original de git-remote-gcrypt fue el usuario de GitHub bluss.
El mantenedor de facto en 2013 y 2014 fue Joey Hess.
El mantenedor actual, desde 2016, es Sean Whitton [email protected].
Este documento y git-remote-gcrypt tienen licencia bajo términos idénticos, GPL-3 (o 2+); consulte el archivo git-remote-gcrypt.
.. this document generates a man page with rst2man .. vim: ft=rst tw=72 sts=4
EncSign(B || L || R)(B, L, R)RHi, KiLHiP'Hash(P')HiP'KiPP