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

File manifesto .............

Esempio di file manifesto (con ellissi per brevità)::

$ 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

Ogni elemento si estende fino a nuova riga e corrisponde a uno dei seguenti:

<sha-1> <gitref> ID oggetto git e suo ref

pack :<hashtype>:<hash> <key> Hash del packfile (Hi) e chiave simmetrica corrispondente (Ki).

keep :<hashtype>:<hash> <generation> Hash del packfile e sua generazione di reimpacchettamento

repo <id> L'id remoto

extn <name> ... Campo di estensione, preservato ma non utilizzato.

Rilevamento di repository gcrypt

Per rilevare se un url git è una repository gcrypt, usa: git-remote-gcrypt --check url Lo stato di uscita è 0 se la repository esiste e può essere decifrata, 1 se la repository usa gcrypt ma non può essere decifrata, e 100 se la repository non è crittografata con gcrypt (o non è accessibile).

Nota che questo deve recuperare il contenuto della repository nella repository git locale, come si fa quando si usa una repository gcrypt.

Problemi noti

Ogni push git ha effettivamente --force. Assicurati di fare pull prima di fare push.

git-remote-gcrypt può decidere di reimpacchettare il remoto senza preavviso, il che significa che il tuo push potrebbe improvvisamente richiedere molto più tempo del previsto, poiché l'intera cronologia deve essere ricaricata. Questo push potrebbe fallire su un collegamento scadente.

git-remote-gcrypt potrebbe segnalare una repository come "non trovata" quando la repository esiste effettivamente, ma git-remote-gcrypt sta avendo problemi di autenticazione, porta o connettività di rete.

Vedi anche

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

Crediti

L'autore originale di git-remote-gcrypt è stato l'utente GitHub bluss.

Il manutentore de facto nel 2013 e 2014 è stato Joey Hess.

L'attuale manutentore, dal 2016, è Sean Whitton [email protected].

Licenza

Questo documento e git-remote-gcrypt sono concessi in licenza con termini identici, GPL-3 (o 2+); vedi il file git-remote-gcrypt.

.. questo documento genera una pagina man con rst2man .. vim: ft=rst tw=72 sts=4

git-remote-gcrypt

Più Popolari