Re: [Tails-dev] Feature #5301 - Clone or Backup Persistent V…

Delete this message

Reply to this message
Autor: sajolida
Data:  
Dla: The Tails public development discussion list, Emma Peel
Temat: Re: [Tails-dev] Feature #5301 - Clone or Backup Persistent Volume
Andrew Gallagher:
> On 13/12/15 17:46, sajolida wrote:
>>
>> If you're interested in plugging this in the current code [1] that would
>> be awesome. But as we haven't really finished the design decision around
>> the backup scenarios, I can't promise anything regarding it's official
>> acceptance yet.
>
> I have a reasonably stable version of the code available here:
>
> https://github.com/andrewgdotcom/tails-clone-persistent/releases/tag/v0.1.1-beta1


Amazing!

> The easiest way to install it is to download the .deb, but it should(?)
> build cleanly from the source. There's nothing particularly fancy in it.


I want to first have a look at what would be the user scenario for this
from a broader perspective in our plans regarding backups in Tails,
before looking at the code.

But we're definitely lacking people writing code in Tails as well,
especially Perl, so it's a good news in and off itself that you can
write Perl and do Debian packages!

I'm still way too busy with finishing deliverables to look at your tool
this week again, but I though maybe Emma Peel (in copy) could be
interested as she's been giving a workshop on Tails backups last week
and 32C3.

> Some notes/caveats:
>
> 1. The GUI half of the code is still perl, sorry. So it's not directly
> pluggable into tails-installer (yet!). It works fine as a standalone
> GTK2 app and invokes tails-installer as required. Working code >> proper
> standards and all that. ;-)
>
> 2. The GUI is not particularly pretty.
>
> 3. My C++ string handling sucks. Please don't look at it. I'll tidy it
> up later.
>
> 4. If you type in the wrong password when updating an existing
> persistent partition, it will fail hard rather than reprompt.
>
> 5. I've been testing it against Tails 2.0beta. It used to work against
> 1.x also, but I might have broken that when I migrated to udisks2.
> Haven't got around to checking it since.