Restoring full backups including keys

[Terrance]

Signal is currently testing a new backup format, and they've noted that identity keys will no longer be included in their backups, meaning you can't restore a backup from a file without forcing a key rotation.

My understanding is that the full backup exports generated by this fork include the whole database, including keys. Can these actually be restored in a way which maintains identity keys on a new device? If not, is that feasible? I had a quick look at the setup flow on another device but can't see a way to choose one of these export files as part of a restore, and I assume completing the sign-in first (with an "official" Signal backup or not) will trigger the key rotation.

[johanw666]

Yes, the full backup just dumps the entire Signal data (minus the cache) so the identity key is in it.

Restoring from a new install isn't possible yet, it is a long standing todo issue. As a workaround you could setup from a dummy number and then do a full restore if Signal deletes the identity key from its backup format.

[Terrance]

Interesting -- I assume the full backup completely replaces all the databases, files etc. so it doesn't actually matter what state the app is in (whether signed in as the right account, or a different one, or not at all); it's just the ability to actually get into the restore UI?

[johanw666]

Yes, it completely replaces it. One warning though - if you do that and keep using the old phone as well without cleaning the data the results might be unexpected. I made that error once with WhatsApp - with a Titanium Backup - and some messages arrived on the old device and some on the new one.

[Terrance]

I've had a quick look at the UI to see where this could fit in -- adding an option to the Transfer or restore account screen probably makes the most sense, which I've had a stab at in 4acd109.

I'm struggling to get the build running locally, and I imagine the call into the import fragment won't actually work like that (not very familiar with Android, though I bet those getActivity() calls won't work if the fragment isn't actually connected to anything), but is this something that could work? Would be nice not to have to set up a second account just to swap back. 🙂

[johanw666]

I made the build, but when I select Restore or transfer, theen "I don't have my old phone" to prevent the buggy transfer, I can only select the stadard Signal restore stream. I don't see the new button.

And there is one thing that should be addressed: if you have enabled the standard Signal backup, the zipfile SignalExport.zip will be encrypted with the same key as the standard backup. When Signal is installed and running it knows that key, but for a fresh install this isn't the case and the resstore will fail. So somewhere we need to ask for that password before calling ImportExportFragment().handleImportEncryptedBackup(). The passworded zipfiles are handled in /util/FileUtilsJW.java.

[Terrance]

Hrm, looks like they've started working on a new restore UI/flow for their cloud backups, and both flows are currently in the app.

This one looks a bit more annoying to hook into. Thinking about this some more, I suspect it might still be subject to change until cloud backups launch proper. Assuming you effectively apply these changes as patches on top of each release, is it worth waiting for the UI to stabilise?

[johanw666]

Waiting until the UI has been fully developed might indeed cost the least work. The password input screen however has to be developed anyway since we can't call an existing one, Signal has no option to manually input the backup password. Although we might borrow from the password verification screen.

[Terrance]

Sorry for the delay; I've just taken another look at this, and it seems like the old flow has now been removed. UI-wise I have this to add a similar new option to the current restore flow.

I did eventually manage to build it locally (it seems to take an eternity both to sync dependencies and to compile the app on my slow HDD) and it currently breaks because getActivity() calls inside ImportExportFragment return null. My Android dev knowledge is pretty limited so I'm not sure what's needed to make this work -- at minimum, the fragment presumably needs associating with the restore screen activities, though I'm not sure what the Kotlin Composable equivalents for that are, or even if fragments are compatible in this way (i.e. do we need a Composable rewrite of ImportExportFragment?).