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