I am interested in working on getting https://labs.riseup.net/code/issues/5301 "Clone or Backup Persistent Volume" implemented. My current process is to just make an encrypted tarball as root while offline, but that's a real pain because there are lots of times I want to get a backup of something important (like a new key) as quick as possible as to prevent loss, and I don't want to be enabling root all the time just to make backups.
I'm wondering if my plan would be considered insecure under the current threat model, however. I was thinking about adding new steps into tails-persistence-setup for backing up the tails persistence partition into an encrypted tarball, and then another one for restoring persistence from a prior backup. The backup step would ensure that persistence has been enabled and mounted, and then go into /live/persistence/TailsData_unlocked/ then run something that would be the equivalent of something like this tar cjf - . | gpg --cipher-algo AES -c - > /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg then test it with something that does something like this cat /home/amnesia/YYYY-MM-DD-backup.tbz2.gpg | gpg - | tar djf - If that gives outputs anything, we give some sort of abort/retry/fail message to the user. If all goes well, then the user has a file they can back up with a secure method. The restore step would do the current delete partition steps (if there was already a persistence partition found) , then most of the current steps to create a partition, but instead of asking the user what they want to use their new partition for, it would instead ask the user to pick an encrypted backup file and would untar it into the directory that the partition was mounted for initialization. Does anything look bad with this plan? CustaiCo
signature.asc
Description: PGP signature
_______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
