gc and encrypted metafiles

[Ryan Schlesinger]

Stéphane,

That would be fantastic!  There was a thread on this list a few months 
back about this exact problem.  We discussed 2 different solutions to 
this problem.
1. Moving the decryption code to a shared location and calling it from 
both places (your proposed solution).
2. Modifying brackup-target to take a command line switch that tells it 
to use local copies of the metadata files (which are not encrypted).

The biggest advantages of #2 are that you don't need to keep private 
keys running around and you don't have to prompt for a password which 
would enable cron usage.  If we do #2, I also propose to modify the 
prune operation to remove the local metadata files as well.

If you look back through the archives I think there are some starting 
patches posted.  I don't know if any more work has been done in this 
direction of if anything made it upstream.  Can anyone confirm?

Ryan

Stéphane Alnet wrote:
> Hello,
>
> I've been using brackup for a while for backup / restore but never
> tried the brackup-target script until tonight. When I tried to do a
> "gc", the script started complaining about invalid lines in the
> metafiles. After inspection it seems that Brackup/Metafile.pm (where
> the problem occurs on line 45) is used by Brackup::Target::gc() but
> without the ad-hoc decryption code found for example in Restore.pm
> ("decrypt_file_if_needed" etc.).
>
> Am I missing something obvious? Should I attempt to move the
> decryption code in Restore.pm to a separate module so that both
> Restore::new() and Target::gc() can use it? (I don't mind doing the
> work, I just want to make sure I'm looking at the right issue.)
>
> Thanks,
> Stéphane
>