Hébergement de code sans connaissances? [fermé]

À la lumière des récentes révélations sur la surveillance gouvernementale généralisée des données stockées par les fournisseurs de services en ligne, les services à connaissance zéro font désormais fureur.

Un service à connaissance zéro est un service où toutes les données sont stockées cryptées avec une clé qui n'est pas stockée sur le serveur. Le chiffrement et le déchiffrement se produisent entièrement du côté client, et le serveur ne voit jamais ni les données en clair ni la clé. Par conséquent, le fournisseur de services n'est pas en mesure de déchiffrer et de fournir les données à un tiers, même s'il le voulait.

Pour donner un exemple: SpiderOak peut être considéré comme une version zéro connaissance de Dropbox.

En tant que programmeurs, nous comptons beaucoup sur nos données les plus sensibles - notre code - et les confions à une classe particulière de fournisseurs de services en ligne: les fournisseurs d'hébergement de code (comme Bitbucket, Assembla, etc.). Je parle bien sûr des référentiels privés ici - le concept de connaissance zéro n'a pas de sens pour les référentiels publics.

Mes questions sont:

1. Existe-t-il des obstacles technologiques à la création d'un service d'hébergement de code à connaissance zéro? Par exemple, y a-t-il quelque chose dans les protocoles réseau utilisés par les systèmes de contrôle de version populaires comme SVN, Mercurial ou Git qui rendrait difficile (ou impossible) la mise en œuvre d'un schéma où les données communiquées entre le client et le serveur sont cryptées avec une clé que le serveur ne connaît pas?

2. Existe-t-il aujourd'hui des services d'hébergement de code à connaissance zéro?

Vous pouvez crypter chaque ligne séparément. Si vous pouvez vous permettre de divulguer vos noms de fichiers et les longueurs de ligne approximatives et les numéros de ligne sur lesquels les modifications de lignes se produisent, vous pouvez utiliser quelque chose comme ceci:

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

Comme chaque ligne est chiffrée séparément (mais avec la même clé), les modifications téléchargées n'impliqueront (comme d'habitude) que les lignes pertinentes.

Si cela ne vous convient pas actuellement, vous pouvez créer deux référentiels Git, un avec du texte en clair et un avec du texte chiffré. Lorsque vous effectuez une validation dans le référentiel en texte brut (qui est local), un hook de validation peut prendre le diff et l'exécuter via le chiffreur de ligne référencé ci-dessus, qui l'appliquerait au référentiel de texte chiffré. Les modifications du référentiel de texte chiffré seraient validées et téléchargées.

Le chiffreur de ligne ci-dessus est agnostique SCM, mais peut lire les fichiers diff unifiés (de texte en clair) et chiffrer les modifications et les appliquer au texte chiffré. Cela le rend utilisable sur n'importe quel SCM qui vous générera un diff unifié (comme Git).

Je ne pense pas qu'il y ait d'obstacles - considérez SVN, ce qui est envoyé au serveur pour le stockage est le delta entre ce que la version précédente et actuelle de votre code - donc vous changez 1 ligne, juste cette ligne est envoyée au serveur. Le serveur le stocke alors «à l'aveugle» sans effectuer aucune inspection des données lui-même. Si vous chiffriez le delta et l'envoyiez à la place, cela n'aurait aucun impact sur le serveur, en fait, vous n'auriez même pas besoin de modifier le serveur.

Il y a d'autres bits qui peuvent être importants, tels que les propriétés des métadonnées qui ne sont pas facilement chiffrables - comme le type MIME - mais d'autres peuvent être chiffrés, par exemple des commentaires dans le journal d'historique, tant que vous savez que vous devez les déchiffrer sur le client à afficher. Je ne sais pas si la structure des répertoires serait visible, je pense qu'elle ne serait pas visible en raison de la façon dont SVN stocke les répertoires, mais c'est possible, je me trompe. Cela peut cependant ne pas vous concerner si le contenu est sécurisé.

Cela signifierait que vous ne pourriez pas avoir un site Web avec les diverses fonctionnalités d'affichage de code, pas de navigateur de référentiel côté serveur ou de visionneuse de journaux. Pas de différences de code, pas d'outils de révision de code en ligne.

Quelque chose comme ça existe déjà, à un point, Mozy stocke vos données cryptées avec votre clé privée (vous pouvez utiliser la leur, et ils font du bruit "si vous perdez votre propre clé, dommage, nous ne pouvons pas restaurer vos données pour vous ", mais c'est plus ciblé sur l'utilisateur ordinaire). Mozy stocke également un historique de vos fichiers, vous pouvez donc récupérer les versions précédentes. Là où ça tombe, c'est que le téléchargement se fait régulièrement, pas de check-in quand vous le souhaitez, et je pense qu'il rejette les anciennes versions lorsque vous manquez d'espace de stockage. Mais le concept est là, ils pourraient le modifier pour fournir un contrôle de source sécurisé en utilisant leur système existant.

Je déteste faire une de ces réponses "ça ne va pas vraiment répondre à votre question" .. mais ..

Je peux penser à deux solutions prêtes à répondre à ces inquiétudes.

1. Hébergez vous-même un serveur Git privé. Ensuite, placez ce serveur sur un VPN auquel vous donnez accès aux membres de votre équipe. Toutes les communications vers et depuis le serveur seraient cryptées, et vous pourriez bien sûr crypter le serveur au niveau du système d'exploitation.

2. BitSync devrait également faire l'affaire. Tout serait crypté, et dans un immense réseau qui serait disponible de n'importe où. Cela pourrait en fait être une très bonne application de toute cette technologie BitCoin / BitMessage / BitSync.

Enfin, les gens sur /security// pourraient avoir plus d'informations.

Si je comprends bien, la façon dont git pullfonctionne est que le serveur vous envoie un fichier pack qui contient tous les objets que vous voulez, mais que vous n'avez pas actuellement. Et vice versa pour git push.

Je pense que vous ne pouvez pas le faire directement comme ça (car cela signifie que le serveur doit comprendre les objets). Ce que vous pourriez faire à la place, c'est de laisser le serveur fonctionner uniquement avec une série de fichiers pack chiffrés.

Pour ce faire pull, vous téléchargez tous les fichiers pack qui ont été ajoutés depuis votre dernier pull, les déchiffrez et appliquez à votre git repo. Pour ce faire push, vous devez d'abord le faire pull, afin de connaître l'état du serveur. S'il n'y a pas de conflits, vous créez un fichier pack avec vos modifications, le cryptez et le téléchargez.

Avec cette approche, vous vous retrouveriez avec un grand nombre de petits fichiers pack, ce qui serait assez inefficace. Pour résoudre ce problème, vous pouvez télécharger une série de fichiers pack, les décrypter, les combiner en un seul fichier pack, les crypter et les télécharger sur le serveur, en les marquant en remplacement de cette série.