Hosting di codice a zero-conoscenza? [chiuso]

Puoi criptare ogni riga separatamente. Se puoi permetterti di trapelare i nomi dei file e le lunghezze delle linee approssimate ei numeri di riga in cui si verificano le linee cambia, puoi usare qualcosa di simile:

link

Poiché ogni riga viene crittografata separatamente (ma con la stessa chiave), le modifiche caricate avranno (come di solito) solo le righe pertinenti.

Se al momento non è abbastanza conveniente, puoi creare due repository Git, uno con testo in chiaro e uno con testo cifrato. Quando si esegue il commit nel repository in chiaro (che è locale), un hook di commit può prendere il diff ed eseguirlo attraverso il codificatore di linea a cui si fa riferimento sopra, che lo applicherà al repository ciphertext. Le modifiche al repository di crittografati verrebbero eseguite e caricate.

Il codificatore di linea sopra è agnostico SCM, ma può leggere file diff unificati (di testo in chiaro) e crittografare le modifiche e applicarle al testo cifrato. Questo lo rende utilizzabile su qualsiasi SCM che ti genererà un diff unificato (come Git).

Non penso ci siano barriere: considera SVN, ciò che viene inviato al server per la memorizzazione è il delta tra ciò che la versione precedente e quella attuale del tuo codice - così cambi 1 linea, solo quella linea viene mandata a il server. Il server quindi "ciecamente" lo memorizza senza eseguire alcuna ispezione dei dati stessi. Se hai crittografato il delta e inviato quello, non ci sarebbe stato alcun impatto sul server, infatti non avresti nemmeno bisogno di modificare il server.

Ci sono altri bit che potrebbero importare, come le proprietà dei metadati che non sono facilmente crittografabili, come il tipo mime, ma altri potrebbero essere crittografati, ad esempio commenti nel registro cronologia, purché tu sappia che devi decifrare loro sul client da visualizzare. Non sono sicuro che la struttura della directory sia visibile, penso che non sarebbe visibile a causa del modo in cui SVN memorizza le directory, ma è possibile che io abbia torto. Questo potrebbe non essere importante per te se il contenuto è sicuro comunque.

Ciò significherebbe che non si può avere un sito Web con le varie funzionalità di visualizzazione del codice, nessun browser di repository sul lato server o log viewer. Nessun codice diff, nessun tool di revisione del codice online.

Esiste già qualcosa del genere, Mozy memorizza i tuoi dati criptati con la tua chiave privata (puoi usarli da soli, e fanno rumori su "se perdi la tua chiave, peccato, non possiamo ripristinare i tuoi dati per te ", ma questo è più mirato all'utente comune). Mozy memorizza anche una cronologia dei tuoi file, così puoi recuperare le versioni precedenti. Dove cade è che il caricamento è su base regolare, non il checkin quando vuoi, e credo che scarta vecchie versioni quando si esaurisce lo spazio di archiviazione. Ma il concetto è lì, potrebbero modificarlo per fornire un sicuro controllo del codice sorgente usando il loro sistema esistente.

Detesto fare una di quelle domande "questo non risponderà alla tua domanda" .. ma ..

Posso pensare a due soluzioni pronte che dovrebbero affrontare queste preoccupazioni.

1. Ospita un server Git privato per conto tuo. Quindi metti quel server su una VPN a cui dai ai membri del tuo team l'accesso. Tutte le comunicazioni da e verso il server sarebbero state crittografate e, ovviamente, è possibile crittografare il server a livello di sistema operativo.

2. BitSync dovrebbe fare anche il trucco. Tutto sarebbe crittografato e in una rete enorme che sarebbe disponibile da qualsiasi luogo. Potrebbe essere davvero una buona applicazione di tutta questa tecnologia BitCoin / BitMessage / BitSync ..

Infine, i membri del link potrebbero avere qualche informazione in più.

A quanto ho capito, il modo in cui git pull funziona è che il server ti manda un file pack che contiene tutti gli oggetti che vuoi, ma che al momento non hanno. E viceversa per git push .

Penso che non potresti farlo direttamente in questo modo (perché questo significa che il server deve capire gli oggetti). Quello che potresti fare è lasciare che il server funzioni solo con una serie di file pack crittografati.

Per fare pull , puoi scaricare tutti i file del pacchetto che sono stati aggiunti dal tuo ultimo pull , decrittografarli e applicarli al tuo repository git. Per fare push , devi prima fare pull , in modo da conoscere lo stato del server. Se non ci sono conflitti, puoi creare un file pack con le tue modifiche, crittografarlo e caricarlo.

Con questo approccio, si finirebbe con un gran numero di piccoli file pack, il che sarebbe piuttosto inefficiente. Per risolvere il problema, è possibile scaricare una serie di file pack, decrittografarli, combinarli in un unico file pack, crittografarli e caricarli sul server, contrassegnandoli come sostituti di quella serie.