Como posso destruir um repositório git razoavelmente rápido?

Question

Estou interessado em remover com precisão um repositório git em um tempo razoável.

Mas leva um bom tempo para fazer isso. Aqui, tenho um pequeno repo de teste em que a pasta .git é < 5 MiB.

$ du -ac ~/tmp/.git | tail -1
4772    total
$ find ~/tmp/.git -type f | wc -l
991

Usando as opções padrão de shred , isso leva bastante tempo. No próximo comando, uso --force para alterar as permissões e --zero para substituir por zeros após a fragmentação. O método de destruição padrão é sobrescrever dados aleatórios três vezes ( -n3 ).

Eu também quero remover os arquivos depois. De acordo com man shred , --remove=wipesync (o padrão, quando --remove é usado) só opera em diretórios, mas isso parece me atrasar mesmo quando eu operei apenas em arquivos. Compare (cada vez que eu reinicializei o repositório do git):

$ time find ~/tmp/.git -type f | xargs shred --force --zero --remove=wipesync
real    8m18.626s
user    0m0.097s
sys     0m1.113s

$ time find ~/tmp/.git -type f | xargs shred --force --zero --remove=wipe
real    0m45.224s
user    0m0.057s
sys     0m0.473s


$ time find ~/tmp/.git -type f | xargs shred --force --zero -n1 --remove=wipe
real    0m33.605s
user    0m0.030s
sys     0m0.110s

Existe uma maneira melhor de fazer isso?

EDIT: Sim, a criptografia é a chave. Agora estou adicionando mais dois benchmarks usando -n0 .

time find ~/tmp/.git -type f | xargs shred --force --zero -n0 --remove=wipe    
real 0m32.907s
user 0m0.020s
sys     0m0.333s

Usando 64% em paraleloshreds:

time find ~/tmp/.git -type f | parallel -j64 shred --force --zero -n0 --remove=wipe
real    0m3.257s
user    0m1.067s
sys     0m1.043s

    

Answer 1

Esqueça o shred , ele gasta muito tempo fazendo coisas inúteis e sente falta do essencial.

shred limpa arquivos fazendo várias passagens de arquivos sobrescritos com dados aleatórios (um “Gutmann wipe”), porque com as tecnologias de disco de 20 a 30 anos atrás e alguns equipamentos caros de laboratório, era possível (pelo menos em teoria) para recuperar dados sobrescritos. Este não é mais o caso das modernas tecnologias de disco: substituir apenas uma vez por zeros é igualmente bom - mas a ideia de múltiplos passes aleatórios permaneceu bem depois de ter se tornado obsoleta. Veja link

Por outro lado, shred falha ao limpar as informações confidenciais, porque apenas limpa os dados nos arquivos que foram instruídos para apagar. Quaisquer dados que foram armazenados em arquivos anteriormente apagados ainda podem ser recuperados acessando-se o disco diretamente, em vez de através do sistema de arquivos. Os dados de uma árvore git podem não ser muito fáceis de reconstruir; no entanto, esta é uma ameaça realista.

Para poder limpar rapidamente alguns dados, encripte-os. Você pode usar ecryptfs (criptografia de diretório inicial) ou encfs (criptografia de uma árvore de diretórios), ou dm-crypt (criptografia de partições inteiras), ou qualquer outro método. Para limpar os dados, basta limpar a chave.

Veja também Como posso ter certeza de que um diretório ou arquivo está realmente excluído?

    

Answer 2

Certifique-se de evitar passagens desnecessárias de sobregravação múltiplas com shred . Por exemplo. use shred -n 1 sem mais nada.

O problema com a exclusão segura de arquivos (com git e em geral) é que toda vez que você edita, clona, alterna ramificações, etc. um novo arquivo (ou conjunto de arquivos) é criado, possivelmente em um local físico diferente . Assim, uma quantidade desconhecida de cópias é vazada no espaço livre do sistema de arquivos.

Até mesmo o sistema de arquivos não sabe onde essas cópias podem estar localizadas, portanto você não pode sobrescrevê-las diretamente, independentemente da ferramenta ou método que você usa. Em vez disso, você precisa sobrescrever todo o espaço livre (que o sistema de arquivos pode não permitir), ou o dispositivo inteiro para ter certeza.

Sobrescrever um disco inteiro leva muito tempo (especialmente se você tiver que copiar os arquivos que deseja manter durante o processo), então a questão é quão importante é a segurança x velocidade para você aqui. / p>

O caminho mais rápido é provavelmente usar apenas rm . Claro, isso não substitui nada.

No entanto, se você já usa SSD, com discard a opção de montagem ou fstrim , é possível eliminar rapidamente a maior parte do espaço livre e não há nenhuma maneira óbvia de recuperar o espaço descartado.

Para uso doméstico, este deve ser um nível de segurança suficiente, mantendo as coisas práticas. Para maiores necessidades de segurança, use criptografia.

shred -n 1 é ótimo para sobrescrever discos inteiros, pois ele grava grandes quantidades de dados (pseudo) aleatórios rapidamente. É rápido o suficiente para utilizar velocidades de disco completas, mesmo para SSD. Como tal, não há desvantagem em relação aos zeros.

A desvantagem de zeros é que o armazenamento pode decidir marcá-los como livres ou compactados, em vez de realmente gravá-los. Algo a considerar quando você não tiver mais controle sobre sua solução de armazenamento (porque ela é avançada o suficiente para ser considerada uma caixa preta ou em um ambiente de virtualização).

    

Answer 3

Acho que, como há muitos arquivos pequenos em um repositório Git, levará muito tempo para que shred os exclua e grave os dados antigos. Eu sugeriria fazer algo um pouco diferente e usar tmpfs para armazenar os dados na RAM. Então, quando tiver terminado, você simplesmente o desmontará e não precisará se preocupar com os dados armazenados em qualquer lugar em seu armazenamento físico.

bash $ mkdir $REPO_NAME
bash $ sudo mount -o uid=$YOUR_USERNAME,gid=$YOUR_GROUP_NAME,size=100m \
> -t tmpfs tmpfs $REPO_NAME
bash $ git clone git://$GIT_SERVER/$REPO_PATH/${REPO_NAME}.git

E quando terminar:

bash $ sudo umount $REPO_NAME
bash $ rmdir $REPO_NAME

Outra opção, que persistirá durante as reinicializações e falhas de energia, é criar um arquivo de imagem de disco com um sistema de arquivos. Quando terminar, shred o arquivo. Deve levar menos tempo do que usar shred em todos os arquivos pequenos no repositório. Você pode salvar isso como dois scripts de shell. (Você precisará editá-los para fazê-los funcionar com o seu repositório real.)

Nota: Estamos usando reiserfs porque ele não cria um diretório lost+found automaticamente como os sistemas de arquivos ext fazem. Você pode usar btrfs ou qualquer outro sistema de arquivos que achar melhor, mas a sintaxe para criá-lo ou montá-lo pode não ser exatamente a mesma.

create_repo.sh

#!/bin/bash
truncate --size 100M $IMAGE_FILE
/sbin/mkfs.reiserfs -fq $IMAGE_FILE
sudo mount -t reiserfs -o loop $IMAGE_FILE $REPO_NAME
chown $YOUR_USERNAME:$YOUR_GROUP_NAME $REPO_NAME
git clone git://$GIT_SERVER/$REPO_PATH/${REPO_NAME}.git

shred_repo.sh

#!/bin/bash
sudo umount $REPO_NAME
rmdir $REPO_NAME
shred $IMAGE_FILE