Как я могу уничтожить репозиторий git, достаточно быстро?

Я заинтересован в точном удалении репозитория git в разумные сроки.

Но для этого требуется довольно много времени. Здесь у меня небольшое тестовое репо, где папка .git составляет <5MiB.

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

Используя настройки по умолчанию для shred , это занимает довольно много времени. В следующей команде я использую --force для изменения разрешений и --zero для перезаписывания нулями после измельчения. Метод измельчения по умолчанию состоит в том, чтобы три раза записывать случайные данные ( -n3 ).

Я также хочу удалить файлы после этого. По словам man shred , --remove=wipesync (по умолчанию, когда используется --remove ) работает только с каталогами, но это, похоже, замедляет меня, даже когда я работаю только с файлами. Сравните (каждый раз, когда я повторно инициализировал 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 

Есть ли лучший способ сделать это?


EDIT: Да, шифрование – это ключ. Теперь я просто добавляю еще два теста, используя -n0 .

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

Использование 64 параллельных shreds :

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

    Забудьте о shred , он тратит много времени на бесполезные вещи и пропускает необходимое.

    shred стирает файлы, делая несколько проходов перезаписи файлов со случайными данными («Gutmann wipe»), потому что с дисковыми технологиями 20-30 лет назад и некоторым дорогостоящим лабораторным оборудованием было возможно (по крайней мере теоретически) восстановить перезаписанные данные. Это уже не так с современными дисковыми технологиями: перезапись только один раз с нулями столь же хороша, но идея множественных случайных проходов оставалась вокруг после того, как она устарела. См. https://security.stackexchange.com/questions/10464/why-is-writing-zeros-or-random-data-over-a-hard-drive-multiple-times-better-th

    С другой стороны, shred полностью терпит неудачу в очистке конфиденциальной информации, поскольку она только стирает данные в файлах, которые, как сказано, стирают. Любые данные, которые были сохранены в ранее удаленных файлах, могут быть восстановлены путем обращения к диску напрямую, а не через файловую систему. Данные из дерева git не могут быть легко реконструированы; тем не менее это реальная угроза.

    Чтобы иметь возможность быстро стереть некоторые данные, зашифруйте их. Вы можете использовать ecryptfs (шифрование домашнего каталога) или encfs (шифрование дерева каталогов) или dm-crypt (шифрование всего раздела) или любой другой метод. Чтобы стереть данные, просто протрите ключ.

    См. Также Как я могу быть уверенным, что каталог или файл действительно удалены?

    Обязательно избегайте ненужных нескольких перезаписываемых проходов с помощью shred . Например, используйте shred -n 1 без каких-либо других целей.

    Проблема с безопасным удалением файлов (с git и вообще) заключается в том, что каждый раз, когда вы редактируете, клонируете, переключаете ветви и т. Д., Создается новый файл (или набор файлов), возможно, в другом физическом месте. Таким образом, неизвестное количество копий попадает в свободное пространство файловой системы.

    Даже файловая система не знает, где эти копии могут быть расположены, поэтому вы не можете их переписывать напрямую, независимо от того, какой инструмент или метод вы используете. Вместо этого вам нужно перезаписать все свободное пространство (которое файловая система может вам не позволить), или все устройство действительно быть уверенным.

    Перезаписывание всего диска занимает много времени (особенно если вам нужно скопировать файлы, которые вы хотите сохранить в этом процессе), поэтому вопрос заключается в том, насколько важна для вас безопасность и скорость.


    Самый быстрый способ – это просто использовать rm вместо этого. Конечно, это ничего не перезаписывает.

    Однако, если вы уже используете SSD, discard опцию mount или fstrim , можно быстро fstrim большую часть свободного пространства, и нет очевидного способа вернуть отброшенное пространство обратно.

    Для домашнего использования это должно быть достаточным уровнем безопасности, сохраняя при этом практичность. Для повышения безопасности необходимо использовать шифрование.

    shred -n 1 отлично подходит для перезаписи целых дисков, поскольку он быстро пишет большие (случайные) случайные данные. Он достаточно быстр, чтобы использовать полную скорость диска, даже для SSD. Таким образом, нет недостатков по сравнению с нулями.

    Недостатком нулей является то, что хранилище может принять решение о том, чтобы отметить как свободный или сжать, а не записывать их. Что-то, что нужно учитывать, если у вас нет правильного контроля над вашим решением для хранения данных (поскольку он достаточно продвинутый, чтобы его можно было рассматривать как черный ящик или среду виртуализации).

    Я думаю, что, поскольку в репозитории Git так много маленьких файлов, для их удаления потребуется много времени, чтобы удалить их и записать старые данные. Я бы предложил сделать что-то немного другое и использовать tmpfs для хранения данных в ОЗУ. Затем, когда вы закончите, вы просто отключите его, и вам не нужно беспокоиться о хранении данных в любом месте вашего физического хранилища.

     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 

    И когда вы закончите:

     bash $ sudo umount $REPO_NAME bash $ rmdir $REPO_NAME 

    Другой вариант, который будет сохраняться при перезагрузках и сбоях питания, – создать файл образа диска с файловой системой на нем. Когда вы закончите, shred файл. Это займет меньше времени, чем использование shred для всех небольших файлов в репо. Вы можете сохранить это как два сценария оболочки. (Вам нужно будет отредактировать их, чтобы они работали с вашим фактическим репо.)

    Примечание. Мы используем reiserfs, потому что он не создает каталог с lost+found автоматически, как это делают файловые системы ext. Вы можете использовать btrfs или любую другую файловую систему, которую вы сочтете нужным, но синтаксис ее создания или установки может быть не совсем таким же.

    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