git-remote-gcrypt

git remote criptografado com GNU Privacy Guard

:Manual section: 1

Descrição

git-remote-gcrypt é um auxiliar de remote do git para fazer push e pull de repositórios criptografados com GnuPG, usando um formato personalizado. Este auxiliar de remote lida com URIs prefixadas com gcrypt::.

Os backends suportados são local, rsync:// e sftp://, onde o repositório é armazenado como um conjunto de arquivos, ou então qualquer <giturl> onde o gcrypt armazenará a mesma representação em um repositório git, através de transporte git arbitrário. Prefira local ou rsync:// se puder usar um deles; veja "Desempenho" abaixo para discussão.

Há também um backend experimental rclone:// apenas para adotantes iniciais (você foi avisado).

O objetivo é fornecer armazenamento git confidencial e autenticado e colaboração usando hosts ou serviços de arquivo típicos não confiáveis.

Instalação ............

• use o gerenciador de pacotes da sua distribuição GNU/Linux -- Debian, Ubuntu, Fedora, Arch e algumas distros menores são conhecidas por ter pacotes

• execute o script install.sh fornecido em outros sistemas

Início rápido ..........

Crie um remote criptografado fazendo push para ele::

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

Configuração

As seguintes variáveis git-config(1) são suportadas:

remote.<name>.gcrypt-participants .. gcrypt.participants Lista separada por espaços de identificadores de chave GPG. O remote é criptografado para esses participantes e apenas assinaturas destes são aceitas. gpg -k lista todas as chaves públicas que você conhece.

Se esta opção não estiver definida, criptografamos para sua chave padrão e aceitamos qualquer assinatura válida. Este comportamento também pode ser solicitado explicitamente definindo participantes como ``simple``.

A configuração ``gcrypt-participants`` no remote tem precedência sobre a variável do repositório ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants Por padrão, os ids das chaves gpg dos participantes são obscurecidos criptografando usando gpg -R. Definir esta opção como true desabilita essa medida de segurança.

O problema de usar ``gpg -R`` é que para descriptografar, o gpg tenta cada chave secreta disponível por vez até encontrar uma chave utilizável.  Isso pode resultar em solicitações de frase secreta desnecessárias.

gcrypt.gpg-args O conteúdo desta configuração é passado como argumentos para o gpg. Ex.: --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (A última da configuração regular do git) A chave a ser usada para assinar. Você deve definir user.signingkey se sua chave de assinatura padrão não fizer parte da lista de participantes. Você pode usar a versão por-remote para assinar diferentes remotes usando diferentes chaves.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Flags a serem passadas para rsync ao fazer upload para um remote usando o backend rsync://. Se as flags forem definidas para um remote específico, as flags globais, se também definidas, não serão aplicadas para aquele remote.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push Um bug de longa data é que todo git push efetivamente tem um --force.

Se esta flag for definida como ``true``, git-remote-gcrypt se recusará a fazer push, a menos que ``--force`` seja passado, ou que as refspecs sejam prefixadas com ``+``.

Há uma solução potencial aqui: https://bugs.debian.org/877464#32

Variáveis de ambiente

GCRYPT_FULL_REPACK Quando definida (para qualquer coisa diferente da string vazia), esta variável de ambiente força um repack completo ao fazer push.

Exemplos

Como configurar um remote para dois participantes::

git remote add cryptremote gcrypt::rsync://example.com/repo
git config remote.cryptremote.gcrypt-participants "KEY1 KEY2"
git push cryptremote master

Como usar um backend git::

# observe que o repositório git de destino já deve existir e sua
# branch `next` será sobrescrita!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

O fragmento de URL (#next aqui) indica qual branch do backend é usada.

Notas

Colaboração A criptografia do manifesto é atualizada a cada push para corresponder à configuração do participante. Cada usuário que faz push deve ter as chaves públicas de todos os colaboradores e a configuração de participantes correta.

Dependências rsync, curl e rclone para remotes rsync:, sftp: e rclone: respectivamente. O executável principal requer um shell compatível com POSIX que suporte local.

GNU Privacy Guard Ambos GPG 1.4 e 2 são suportados. Você precisa de uma chave GPG pessoal. A configuração do GPG se aplica às escolhas de algoritmo para criptografia de chave pública, criptografia simétrica e assinatura. Veja man gpg para mais informações.

Remote ID O Remote ID não é secreto; ele apenas garante que dois repositórios assinados pelo mesmo usuário possam ser distinguidos. Você verá um aviso se o Remote ID mudar, o que só deve acontecer se o remote foi recriado.

Desempenho Usar um <giturl> arbitrário ou um URI sftp:// requer o upload de todo o histórico do repositório a cada push. Isso significa que os pushes do seu repositório se tornam mais lentos com o tempo, à medida que seu histórico git fica mais longo, e pode facilmente chegar ao ponto em que o uso contínuo do git-remote-gcrypt se torna impraticável.

Portanto, você deve usar esses backends apenas quando souber que seu repositório nunca crescerá muito, não apenas que não é grande agora.  Isso significa que esses backends são inadequados para a maioria dos repositórios e provavelmente adequados apenas para casos incomuns, como pequenos armazenamentos de credenciais.  Mesmo assim, use `rsync://` se puder.  Observe, no entanto, que `rsync://` não funcionará com um serviço de hospedagem de repositórios como Gitolite, GitHub ou GitLab.

URIs rsync O formato URI para o backend rsync é rsync://user@host/path, que se traduz no local rsync user@host:/path, acessado via ssh. Observe que o caminho é absoluto, não relativo ao diretório home. Um formato URI anterior não padrão também é suportado: rsync://user@host:path, que se traduz no local rsync user@host:path

Backend rclone Além de adicionar o backend rclone como um remote com URI como gcrypt::rclone://remote:subdir, você também deve adicionar o remote à configuração do rclone. Isso normalmente é feito executando rclone config. Veja rclone(1).

O backend rclone é considerado experimental e é apenas para adotantes iniciais.  Você foi avisado.

Formato do repositório .................

| EncSign(X): Assinar e Criptografar para o detentor da chave GPG | Encrypt(K,X): Criptografar usando algoritmo de chave simétrica | Hash(X): SHA-2/256 | | B: lista de branches | L: lista do hash (Hi) e chave (Ki) para cada arquivo de pacote | R: Remote ID | | Para escrever o repositório: | | Armazenar cada arquivo de pacote P como Encrypt(Ki, P) → P' no arquivo Hi | onde Ki é uma nova string aleatória e Hash(P') → Hi | Armazenar no manifesto | | Para ler o repositório: | | Obter o manifesto, descriptografar e verificar usando o chaveiro GPG → | Avisar se não coincidir com o Remote ID visto anteriormente | para cada em : | Obter o arquivo do servidor → | Verificar se corresponde a | Descriptografar usando → então abrir com git

Arquivo de manifesto .............

Exemplo de arquivo de manifesto (com reticências por brevidade)::

$ 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 item se estende até a nova linha e corresponde a um dos seguintes:

<sha-1> <gitref> ID do objeto git e sua ref

pack :<hashtype>:<hash> <key> Hash do packfile (Hi) e chave simétrica correspondente (Ki).

keep :<hashtype>:<hash> <generation> Hash do packfile e sua geração de repack

repo <id> O id do remote

extn <name> ... Campo de extensão, preservado mas não utilizado.

Detectando repositórios gcrypt

Para detectar se uma url git é um repositório gcrypt, use: git-remote-gcrypt --check url O status de saída é 0 se o repositório existe e pode ser descriptografado, 1 se o repositório usa gcrypt mas não pôde ser descriptografado, e 100 se o repositório não está criptografado com gcrypt (ou não pôde ser acessado).

Observe que isso precisa buscar o conteúdo do repositório para o repositório git local, da mesma forma que é feito ao usar um repositório gcrypt.

Problemas conhecidos

Todo git push efetivamente tem --force. Certifique-se de puxar antes de empurrar.

git-remote-gcrypt pode decidir fazer repack do remote sem aviso, o que significa que seu push pode de repente levar significativamente mais tempo do que você esperava, pois todo o seu histórico precisa ser reenviado. Esse push pode falhar em uma conexão ruim.

git-remote-gcrypt pode relatar um repositório como "não encontrado" quando o repositório de fato existe, mas git-remote-gcrypt está tendo problemas de autenticação, porta ou conectividade de rede.

Veja também

git-remote-helpers(1), gpg(1)

Créditos

O autor original do git-remote-gcrypt foi o usuário do GitHub bluss.

O mantenedor de fato em 2013 e 2014 foi Joey Hess.

O mantenedor atual, desde 2016, é Sean Whitton [email protected].

Licença

Este documento e git-remote-gcrypt são licenciados sob termos idênticos, GPL-3 (ou 2+); veja o arquivo git-remote-gcrypt.

.. this document generates a man page with rst2man .. vim: ft=rst tw=72 sts=4