Hosting di codice a conoscenza zero? [chiuso]

Alla luce delle recenti rivelazioni sul diffuso monitoraggio da parte del governo dei dati archiviati dai fornitori di servizi online, i servizi a conoscenza zero sono di gran moda ora.

Un servizio a conoscenza zero è uno in cui tutti i dati sono archiviati crittografati con una chiave che non è memorizzata sul server. La crittografia e la decrittografia avvengono interamente sul lato client e il server non vede mai né i dati in chiaro né la chiave. Di conseguenza, il fornitore di servizi non è in grado di decrittografare e fornire i dati a terzi, anche se lo desiderasse.

Per fare un esempio: SpiderOak può essere visualizzato come una versione a conoscenza zero di Dropbox.

Come programmatori, facciamo molto affidamento e affidiamo alcuni dei nostri dati più sensibili - il nostro codice - a una particolare classe di fornitori di servizi online: fornitori di hosting di codice (come Bitbucket, Assembla e così via). Sto ovviamente parlando di repository privati ​​qui - il concetto di conoscenza zero non ha senso per i repository pubblici.

Le mie domande sono:

1. Esistono ostacoli tecnologici alla creazione di un servizio di hosting di codice a conoscenza zero? Ad esempio, c'è qualcosa nei protocolli di rete utilizzati dai sistemi di controllo versione popolari come SVN, Mercurial o Git che renderebbe difficile (o impossibile) implementare uno schema in cui i dati che vengono comunicati tra il client e il server sono crittografati con una chiave che il server non conosce?

2. Esistono attualmente servizi di hosting di codice a conoscenza zero?

È possibile crittografare ciascuna riga separatamente. Se puoi permetterti di perdere i nomi dei file e la lunghezza approssimativa delle linee e i numeri delle linee su cui si verificano le modifiche delle linee, puoi usare qualcosa del genere:

https://github.com/ysangkok/line-encryptor

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

Se al momento non è abbastanza conveniente, potresti creare due repository Git, uno con testo in chiaro e uno con testo cifrato. Quando esegui il commit nel repository di testo in chiaro (che è locale), un hook di commit potrebbe prendere il diff ed eseguirlo attraverso il codificatore di linea sopra indicato, che lo applicherebbe al repository di testo cifrato. Le modifiche al repository di testo cifrato verrebbero salvate e caricate.

Il codificatore di riga sopra è SCM agnostico, 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 genererà un diff unificato (come Git).

Non credo che ci siano ostacoli - considera SVN, ciò che viene inviato al server per l'archiviazione è il delta tra quello che la versione precedente e quella attuale del tuo codice - quindi cambi 1 riga, solo quella riga viene inviata al server. Il server quindi lo memorizza "alla cieca" senza fare alcuna ispezione dei dati stessi. Se si crittografasse il delta e lo si inviasse invece, non ci sarebbe alcun impatto sul server, in effetti non sarebbe nemmeno necessario modificarlo affatto.

Ci sono altri bit che potrebbero interessare, come le proprietà dei metadati che non sono facilmente crittografabili - come il tipo mime - ma altri potrebbero essere crittografati, ad esempio commenti nel registro cronologico, purché tu sappia che devi decrittografarli sul client da visualizzare. Non sono sicuro che la struttura delle directory sia visibile, penso che non sarebbe visibile a causa del modo in cui SVN archivia le directory, ma è possibile che mi sbagli. Questo potrebbe non importarti se i contenuti sono comunque sicuri.

Ciò significherebbe che non è possibile avere un sito Web con le varie funzionalità di visualizzazione del codice, nessun browser di repository sul lato server o visualizzatore di log. Nessuna differenza di codice, nessuno strumento di revisione del codice online.

Qualcosa del genere esiste già, a un certo punto, Mozy memorizza i tuoi dati crittografati con la tua chiave privata (puoi usarne uno proprio e fanno dei rumori su "se perdi la tua chiave, peccato, non possiamo ripristinare i tuoi dati per tu ", ma è più mirato all'utente comune). Mozy memorizza anche una cronologia dei tuoi file, in modo da poter recuperare le versioni precedenti. Il problema è che il caricamento è su base regolare, non il check-in quando lo si desidera e credo che scarti le vecchie versioni quando si esaurisce lo spazio di archiviazione. Ma il concetto è lì, potrebbero modificarlo per fornire un controllo sicuro del codice sorgente usando il loro sistema esistente.

Odio fare una di quelle risposte "questa non è abbastanza per rispondere alla tua domanda" .. ma ..

Mi vengono in mente due soluzioni pronte che dovrebbero affrontare queste preoccupazioni.

1. Ospita un server Git privato da solo. Quindi metti quel server su una VPN a cui dai accesso ai membri del tuo team. Tutte le comunicazioni da e verso il server sarebbero crittografate e si potrebbe ovviamente 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 davvero essere un'ottima applicazione di tutta questa tecnologia BitCoin / BitMessage / BitSync.

Infine, la gente su /security// potrebbe avere qualche informazione in più.

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

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

Per fare ciò pull, scarichi tutti i file del pacchetto che sono stati aggiunti dal tuo ultimo pull, li decifrano e li applichi al tuo repository git. Per fare push, devi prima fare pull, in modo da conoscere lo stato del server. Se non ci sono conflitti, si crea un file pack con le modifiche, lo si crittografa e lo si carica.

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