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 .....................