gitリポジトリを適度に高速に細断処理するにはどうすればよいですか？
妥当な時間内にgitリポジトリを正確に削除することに興味があります。
しかし、そうするのにはかなりの時間がかかります。ここに、.gitフォルダーが5MiB未満の小さなテストリポジトリがあります。
$ du -ac ~/tmp/.git | tail -1
4772 total
$ find ~/tmp/.git -type f | wc -l
991
shredのデフォルトオプションを使用すると、これにはかなり時間がかかります。次のコマンドでは、--forceを使用して権限を変更し、--zeroを使用して細断処理後にゼロで上書きします。デフォルトのシュレッダー方法は、ランダムデータで3回上書きすることです（-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
それを行うためのより良い方法はありますか？
編集：はい、暗号化が鍵です。 -n0を使用してさらに2つのベンチマークを追加しています。
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ワイプ」）。これは、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 （パーティション全体の暗号化）を使用できます。 ）、またはその他の方法。データをワイプするには、キーをワイプするだけです。
Gitリポジトリには非常に多くの小さなファイルがあるため、shredがそれらを削除して古いデータを上書きするのに長い時間がかかると思います。少し違うことをして、tmpfsを使用してデータをRAMに保存することをお勧めします。次に、完了したら、マウントを解除するだけで、物理ストレージのどこにでも格納されているデータについて心配する必要はありません。
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を使用するよりも時間がかからないはずです。これを2つのシェルスクリプトとして保存できます。 （実際のリポジトリで機能させるには、それらを編集する必要があります。）
注：私たちはreiserfsを使用しています。これは、extファイルシステムのようにlost+foundディレクトリが自動的に作成されないためです。 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
shredを使用した不要な複数の上書きパスは避けてください。例えば。使用する shred -n 1何もなし。
安全なファイル削除（gitおよび一般的に）の問題は、ブランチを編集、複製、切り替えなどするたびに、新しいファイル（またはファイルのセット）が、おそらく異なる物理的な場所に作成されることです。 。したがって、未知の量のコピーがファイルシステムの空き領域にリークされます。
ファイルシステムでさえ、それらのコピーがどこにあるかを知らないので、使用するツールや方法に関係なく、それらを直接上書きすることはできません。代わりに、空き領域全体（ファイルシステムでは許可されない場合があります）、またはデバイス全体を上書きする必要があります。
ディスク全体の上書きには長い時間がかかります（特に、プロセスで保持したいファイルをコピーする必要がある場合）。したがって、ここで問題となるのは、セキュリティと速度のどちらが本当に重要かということです。
おそらく最速の方法は、代わりにrmを使用することです。もちろん、それは何も上書きしません。
ただし、すでにSSDを使用している場合は、discardマウントオプションまたはfstrimを使用すると、空き領域のほとんどをすばやく破棄でき、破棄された領域を元に戻す明確な方法はありません。
家庭で使用する場合、これは物事を実用的に保ちながら、十分なレベルのセキュリティである必要があります。より強力なセキュリティニーズのために、暗号化を使用してください。
shred -n 1は、大量の（疑似）ランダムデータをすばやく書き込むという点で、ディスク全体を上書きするのに最適です。 SSDの場合でも、フルディスク速度を利用するのに十分な速度です。そのため、ゼロと比較してマイナス面はありません。
ゼロの欠点は、ストレージが実際に書き込むのではなく、空きとしてマークするか圧縮するかを決定する可能性があることです。ストレージソリューションを真に制御できなくなったときに考慮すべき点（ブラックボックスと見なされるほど、または仮想化環境で十分に進んでいるため）。