================= git-remote-gcrypt

---

Remote git criptata con GNU Privacy Guard

:Sezione manuale: 1

Descrizione

git-remote-gcrypt è un helper remoto per git per eseguire push e pull da repository crittografate con GnuPG, utilizzando un formato personalizzato. Questo helper remoto gestisce URI con prefisso gcrypt::.

I backend supportati sono local, rsync:// e sftp://, dove la repository viene archiviata come insieme di file, oppure qualsiasi <giturl> dove gcrypt memorizzerà la stessa rappresentazione in una repository git, ponte attraverso un trasporto git arbitrario. Preferisci local o rsync:// se puoi usarne uno; consulta "Prestazioni" più avanti per una discussione.

Esiste anche un backend sperimentale rclone:// solo per primi adottanti (sei stato avvertito).

L'obiettivo è fornire archiviazione git riservata e autenticata e collaborazione utilizzando tipici host o servizi di file non fidati.

Installazione ............

• usa il gestore pacchetti della tua distribuzione GNU/Linux -- Debian, Ubuntu, Fedora, Arch e alcune distribuzioni minori hanno pacchetti noti

• esegui lo script install.sh fornito su altri sistemi

Avvio rapido ..........

Crea una repository remota criptata facendo push::

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

Configurazione

Sono supportate le seguenti variabili git-config(1):

remote.<name>.gcrypt-participants .. gcrypt.participants Elenco separato da spazi di identificatori di chiavi GPG. La repository remota è crittografata per questi partecipanti e vengono accettate solo le firme provenienti da questi. gpg -k elenca tutte le chiavi pubbliche che conosci.

Se questa opzione non è impostata, crittografiamo per la tua chiave predefinita e accettiamo
qualsiasi firma valida. Questo comportamento può anche essere richiesto esplicitamente
impostando i partecipanti su ``simple``.

L'impostazione ``gcrypt-participants`` sul remoto ha la precedenza
sulla variabile repository ``gcrypt.participants``.

remote.<name>.gcrypt-publish-participants .. gcrypt.publish-participants Per impostazione predefinita, gli ID delle chiavi gpg dei partecipanti sono oscurati crittografando usando gpg -R. Impostando questa opzione su true si disabilita quella misura di sicurezza.

Il problema dell'uso di ``gpg -R`` è che per decifrare, gpg prova ogni
chiave segreta disponibile a turno fino a trovare una chiave utilizzabile.
Questo può provocare richieste di passphrase non necessarie.

gcrypt.gpg-args Il contenuto di questa impostazione viene passato come argomenti a gpg. Ad es. --use-agent.

remote.<name>.gcrypt-signingkey .. user.signingkey (Il secondo dalla normale configurazione git) La chiave da usare per firmare. Dovresti impostare user.signingkey se la tua chiave di firma predefinita non fa parte dell'elenco dei partecipanti. Puoi usare la versione per-remote per firmare remoti diversi con chiavi diverse.

remote.<name>.gcrypt-rsync-put-flags .. gcrypt.rsync-put-flags Flag da passare a rsync durante il caricamento su un remoto usando il backend rsync://. Se i flag sono impostati per un remoto specifico, i flag globali, se anche impostati, non verranno applicati per quel remoto.

remote.<name>.gcrypt-require-explicit-force-push .. gcrypt.require-explicit-force-push Un bug di vecchia data è che ogni push git ha effettivamente un --force.

Se questo flag è impostato su ``true``, git-remote-gcrypt rifiuterà di fare push,
a meno che non venga passato ``--force``, o che i refspec siano preceduti da ``+``.

Esiste una potenziale soluzione qui: https://bugs.debian.org/877464#32

Variabili d'ambiente

GCRYPT_FULL_REPACK Quando impostata (a qualsiasi valore diverso dalla stringa vuota), questa variabile d'ambiente forza un reimpacchettamento completo durante il push.

Esempi

Come configurare un remoto per due partecipanti::

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

Come usare un backend git::

# nota che la repository git di destinazione deve già esistere e il suo
# branch `next` verrà sovrascritto!
git remote add gitcrypt gcrypt::[email protected]:repo#next
git push gitcrypt master

Il frammento di URL (#next qui) indica quale branch del backend viene utilizzato.

Note

Collaborazione La crittografia del manifesto viene aggiornata per ogni push per corrispondere alla configurazione dei partecipanti. Ogni utente che fa push deve avere le chiavi pubbliche di tutti i collaboratori e la corretta configurazione dei partecipanti.

Dipendenze rsync, curl e rclone per i remoti rsync:, sftp: e rclone: rispettivamente. L'eseguibile principale richiede una shell POSIX-compliant che supporti local.

GNU Privacy Guard Sono supportati sia GPG 1.4 che 2. Necessiti di una chiave GPG personale. La configurazione GPG si applica alle scelte algoritmiche per la crittografia a chiave pubblica, la crittografia simmetrica e la firma. Vedi man gpg per maggiori informazioni.

ID remoto L'ID remoto non è segreto; assicura solo che due repository firmate dallo stesso utente possano essere distinte. Vedrai un avviso se l'ID remoto cambia, cosa che dovrebbe accadere solo se il remoto è stato ricreato.

Prestazioni L'uso di un <giturl> arbitrario o di un URI sftp:// richiede il caricamento dell'intera cronologia della repository con ogni push. Questo significa che i push della tua repository diventano più lenti nel tempo, man mano che la tua cronologia git diventa più lunga, e può facilmente arrivare al punto in cui l'uso continuato di git-remote-gcrypt è impraticabile.

Pertanto, dovresti usare questi backend solo quando sai che la tua
repository non diventerà mai molto grande, non solo che non è grande
ora.  Ciò significa che questi backend sono inadatti per la maggior
parte delle repository e probabilmente adatti solo per casi insoliti,
come piccoli archivi di credenziali.  Anche in tal caso, usa `rsync://` se
puoi.  Tuttavia, nota che `rsync://` non funziona con un servizio di hosting
di repository come Gitolite, GitHub o GitLab.

URI rsync Il formato URI per il backend rsync è rsync://user@host/path, che si traduce nella posizione rsync user@host:/path, accesso via ssh. Nota che il percorso è assoluto, non relativo alla directory home. È supportato anche un formato URI precedente non standard: rsync://user@host:path, che si traduce nella posizione rsync user@host:path

Backend rclone Oltre ad aggiungere il backend rclone come remoto con URI come gcrypt::rclone://remote:subdir, devi anche aggiungere il remoto alla configurazione rclone. Questo viene tipicamente fatto eseguendo rclone config. Vedi rclone(1).

Il backend rclone è considerato sperimentale ed è solo per primi
adottanti.  Sei stato avvertito.

Formato della repository .................