This also adds a fake nsIOSKeyStore implementation for our xpcshell tests. This
should allow us to run these tests on apple_silicon in automation.
Differential Revision: https://phabricator.services.mozilla.com/D215707
Clean up intermediate artifacts in order to be kind to users' disk space:
- remove staging folder after compressing the staging folder into a new single ZIP file
- remove that single ZIP file after embedding its contents into the backup HTML file
Differential Revision: https://phabricator.services.mozilla.com/D215542
This implements getting the information needed to show the date of a backup in the restore component and showing the password input if that backup is encrypted.
- Adds a `getBackupFileInfo` method to `BackupService` that will call `sampleArchive` for a passed backup file and update the `backupFileInfo` in the state with a subset of that info.
- Update the `GetBackupFileInfo` event handler in `BackupUIParent` to use the new `getBackupFileInfo` method.
Differential Revision: https://phabricator.services.mozilla.com/D214899
This implements getting the information needed to show the date of a backup in the restore component and showing the password input if that backup is encrypted.
- Adds a `getBackupFileInfo` method to `BackupService` that will call `sampleArchive` for a passed backup file and update the `backupFileInfo` in the state with a subset of that info.
- Update the `GetBackupFileInfo` event handler in `BackupUIParent` to use the new `getBackupFileInfo` method.
Differential Revision: https://phabricator.services.mozilla.com/D214899
Since the ArchiveJSONBlock uses a $ref to reference the metadata in the
BackupManifest schema, we have to change the JSON validation mechanism
we're using to one that supports $ref's.
Differential Revision: https://phabricator.services.mozilla.com/D212860
Factoring this out, as computing these keys is something that we need to do both
when generating the ArchiveEncryptionState, as well as when performing a
decryption.
This also renames "authKey" and "encKey" in ArchiveEncryptionState to use
"backupAuthKey" and "backupEncKey", as these are more in-line with what the
encryption design document uses (and because there are "authKeys" and "encKeys"
that will be used by the encryption mechanism that are distinct from the
backupAuthKey and backupEncKey).
Differential Revision: https://phabricator.services.mozilla.com/D212858
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
There are a number of interesting things going on this patch that I think are worth highlighting
here for my reviewers:
1. The single-file archive format is an HTML file that uses an inlined multipart/mixed MIME
message within a HTML document comment in order to embed the backup data into the archive.
2. We use the multipart/mixed nsIStreamConverter to extract the JSON and binary data from
the MIME block.
3. We use a Archive Worker to do the archive creation, allowing us to do the work of construction
off of the main thread.
4. The Archive Worker is only parsing the header and getting the byte offset of the MIME block.
Extraction is happening in the parent process. This is mainly for simplicity for now, since
the Archive Worker cannot invoke an nsIStreamConverter. Down the line, if we determine that
we'd prefer the Archive Worker do the base64 decoding off of the main thread, we may need
to use a Message Channel to send the byte sfrom the nsIStreamConverter to it, and add
stream-writing support to IOUtils so that the Archive Worker can take care of sending the
decoded bytes to disk.
5. The patch doesn't expose the extraction mechanism in any way except through the debug
interface right now. That will come down the line. In the meantime, this mechanism
can be manually tested in the debug interface by creating a backup, which should also
create an "archive.html" file in the backups folder. Using the "Extract from archive"
button in the debug tool will let you select that HTML file and extract the ZIP as
a file in the backups folder called "extraction.zip".
6. The test template contains Unicode characters because certain locales might involve
us writing Unicode characters in the HTML template when generating the archive. The
fun part about that is calculating where the byte offset is for the MIME block! See
the comment in the Archive.worker.mjs script for how that works.
Differential Revision: https://phabricator.services.mozilla.com/D211588
