Hospedagem de código de conhecimento zero? [fechadas]

À luz de revelações recentes sobre o amplo monitoramento governamental de dados armazenados por provedores de serviços on-line, os serviços de conhecimento zero estão na moda agora.

Um serviço de conhecimento zero é aquele em que todos os dados são armazenados criptografados com uma chave que não é armazenada no servidor. A criptografia e descriptografia acontecem inteiramente no lado do cliente, e o servidor nunca vê os dados de texto sem formatação ou a chave. Como resultado, o provedor de serviços não pode descriptografar e fornecer os dados a terceiros, mesmo que deseje.

Para dar um exemplo: SpiderOak pode ser visto como uma versão de conhecimento zero do Dropbox.

Como programadores, confiamos bastante e confiamos em alguns de nossos dados mais confidenciais - nosso código - a uma classe específica de provedores de serviços online: provedores de hospedagem de código (como Bitbucket, Assembla etc.). É claro que estou falando de repositórios privados aqui - o conceito de conhecimento zero não faz sentido para repositórios públicos.

Minhas perguntas são:

1. Existem barreiras tecnológicas para criar um serviço de hospedagem de código de conhecimento zero? Por exemplo, existe algo nos protocolos de rede usados ​​por sistemas de controle de versão populares como SVN, Mercurial ou Git que dificultariam (ou impossibilitassem) implementar um esquema no qual os dados que estão sendo comunicados entre o cliente e o servidor são criptografados com uma chave que o servidor não sabe?

2. Existe algum serviço de hospedagem de código de conhecimento zero hoje em dia?

Você pode criptografar cada linha separadamente. Se você pode vazar os nomes dos arquivos, os comprimentos aproximados das linhas e os números das linhas nas quais ocorrem alterações nas linhas, use algo como:

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

Como cada linha é criptografada separadamente (mas com a mesma chave), as alterações carregadas (como geralmente) envolvem apenas as linhas relevantes.

Se atualmente não for conveniente o suficiente, você poderá criar dois repositórios Git, um com texto sem formatação e outro com texto cifrado. Quando você confirma no repositório de texto sem formatação (que é local), um gancho de confirmação pode pegar o diff e executá-lo através do criptografador de linha mencionado acima, que o aplicaria ao repositório de texto cifrado. As alterações no repositório de texto cifrado seriam confirmadas e enviadas.

O criptografador de linha acima é independente do SCM, mas pode ler arquivos diff unificados (de texto sem formatação) e criptografar as alterações e aplicá-las ao texto cifrado. Isso o torna utilizável em qualquer SCM que gere um diff unificado (como o Git).

Acho que não existem barreiras - considere o SVN, o que é enviado ao servidor para armazenamento é o delta entre a versão anterior e a atual do seu código - para que você altere 1 linha, apenas essa linha é enviada ao servidor. O servidor então o armazena 'às cegas' sem fazer nenhuma inspeção dos dados em si. Se você criptografasse o delta e o enviasse, não haveria impacto no servidor; na verdade, você nem precisaria modificar o servidor.

Existem outros bits que podem ser importantes, como propriedades de metadados que não são facilmente criptografáveis ​​- como o tipo mime - mas outros podem ser criptografados, por exemplo, comentários no log do histórico, desde que você saiba que precisa descriptografá-los no cliente para visualizar. Não tenho certeza se a estrutura de diretórios seria visível, acho que não seria visível devido à maneira como o SVN armazena diretórios, mas é possível que eu esteja errado. Isso pode não lhe interessar se o conteúdo estiver seguro.

Isso significa que você não pode ter um site com os vários recursos de exibição de código, nenhum navegador de repositório no servidor ou visualizador de logs. Sem diferenças de código, sem ferramentas de revisão de código online.

Algo assim já existe, até certo ponto, o Mozy armazena seus dados criptografados com sua chave privada (você pode usar os deles e eles fazem barulho sobre "se você perder sua própria chave, muito ruim, não podemos restaurar seus dados para você ", mas isso é mais direcionado ao usuário comum). O Mozy também armazena um histórico dos seus arquivos, para que você possa recuperar as versões anteriores. O problema é que o upload é feito regularmente, e não é feito quando você deseja fazer o check-in, e acredito que ele descarta versões antigas quando o espaço de armazenamento está acabando. Mas o conceito existe, eles podem modificá-lo para fornecer controle de fonte seguro usando o sistema existente.

Eu odeio fazer uma dessas respostas 'isso não vai responder à sua pergunta' .. mas ..

Posso pensar em duas soluções prontas que devem resolver essas preocupações.

1. Hospede um servidor Git privado por conta própria. Em seguida, coloque esse servidor em uma VPN à qual você concede acesso aos membros da sua equipe. Toda a comunicação de e para o servidor seria criptografada e, é claro, você poderia criptografar o servidor no nível do sistema operacional.

2. O BitSync também deve fazer o truque. Tudo seria criptografado e em uma enorme rede que estaria disponível de qualquer lugar. Pode ser realmente uma boa aplicação de toda essa tecnologia BitCoin / BitMessage / BitSync.

Por fim, as pessoas em https://security.stackexchange.com/ podem ter mais informações.

Pelo que entendi, a maneira como git pullfunciona é que o servidor envie um arquivo de pacote que contém todos os objetos que você deseja, mas que não possui atualmente. E vice-versa para git push.

Eu acho que você não poderia fazer isso diretamente (porque isso significa que o servidor precisa entender os objetos). O que você pode fazer é deixar o servidor funcionar apenas com uma série de arquivos de pacote criptografados.

Para fazer isso pull, você baixa todos os arquivos do pacote que foram adicionados desde o seu último pull, descriptografa-os e aplica-se ao seu repositório git. Para fazer push, você primeiro precisa fazer pull, para que você saiba o estado do servidor. Se não houver conflitos, você cria um arquivo de pacote com suas alterações, criptografa e carrega.

Com essa abordagem, você acabaria com um grande número de arquivos de pacotes minúsculos, o que seria bastante ineficiente. Para corrigir isso, você pode baixar uma série de arquivos de pacote, descriptografar, combiná-los em um arquivo de pacote, criptografar e enviá-los ao servidor, marcando-os como um substituto para essa série.