Як автоматично видалити вихідні файли після шифрування за допомогою GPG?

Мені потрібно використовувати GPG в папці з великою кількістю файлів і папок. Я можу використовувати для цього "find" + "gpg" і можу зашифрувати всі файли, але моя проблема полягає в тому, що GPG не видаляє вихідний файл після успішного шифрування.

Який найкращий та найбезпечніший спосіб видалити вихідний файл (файли) після GPG, чи правильно він шифрується? Я не хочу видаляти свої файли передчасно, і я не хочу видаляти незашифровані файли (через помилку, дозвіл тощо, проблеми з роботою GPG) неналежним чином.

Дякую

shred звучить як ваша зброя вибору для безпечного видалення файлів, але див. нижче щодо обмежень файлової системи.

І якщо ви використовуєте термінал, деякі сценарії bash / sh можуть бути корисними. Якщо ви хочете використовувати один рядок, що перевіряє помилку? Так, щоб перемістити файл, якщо він зашифрований правильно, та роздрукувати повідомлення, якщо воно не було?

gpg --encrypt <options> "$file" && mv "$file" todel-folder || echo "Error, $file did not encrypt"

Або ви можете скласти кілька рядкових елементів "якщо успіх" і "якщо не вдасться" для ведення журналу, використовуючи кілька фігурних дужок:

gpg --encrypt <options> "$file" && {
  echo "gpg on $file successful" >> logfile
  mv "$file" todel-folder
  } || {
  echo "Error, $file did not encrypt" >> logfile
}

А потім після цього ви можете безпечно видалити / витерти / зберегти shredфайли todel-folderабо просто подрібнити їх відразу, а не використовувати mv:

gpg --encrypt <options> "$file" && {
    echo "gpg on $file successful" >> logfile
    shred "$file" && { 
        echo "shred on $file successful" >> logfile
        } ||  {
        echo "shred on $file successful" >> logfile
        }
    } || {
    echo "Error, $file did not encrypt" >> logfile
}

Перегляньте man shredкілька варіантів та попереджень:

shred - overwrite a file to hide its contents, and optionally delete it

ОБЕРЕЖНО: Зауважте, що shred спирається на дуже важливе припущення: що файлова система перезаписує дані на місці. Це традиційний спосіб робити речі, але багато сучасних дизайнів файлової системи не задовольняють це припущення. Нижче наведено приклади файлових систем, на яких клаптик не є ефективним або не гарантовано є ефективним у всіх режимах файлової системи:

• Файлові системи, структуровані журналом, або файли, що містяться в журналі, такі як постачаються з AIX та Solaris (і JFS, ReiserFS, XFS, Ext3 тощо)

• файлові системи, які записують зайві дані та продовжують роботу, навіть якщо деякі записи не вдається, наприклад, файлові системи на основі RAID

• файлові системи, які роблять знімки, такі як NFS-сервер Network Appliance

• файлові системи, які кешують у тимчасових місцях, таких як клієнти NFS версії 3

• стислі файлові системи

Що стосується файлових систем ext3, вищезазначена відмова від відповідальності застосовується (і, таким чином, клаптики мають обмежену ефективність) лише в режимі data = journal, який журнали зберігає дані на додаток до лише метаданих. І в режимах даних = упорядкований (за замовчуванням), і в даних = списання, клаптик працює як завжди. Режими журналу Ext3 можна змінити, додавши параметри даних = щось у параметри кріплення для певної файлової системи у файлі
/ etc / fstab, як це зафіксовано на сторінці керівника монтування (man mount).