Bug 1897498 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This worker should:

1. Take in a URL or handle to a local ZIP file. It might be a file URI, or maybe an nsIInputStream or ReadableStream (which can be sent to workers)
2. Have the worker accept some items from an ArchiveEncryptionState if encryption is enabled. Those things are the public key, the salt, the backup auth key, and the wrapped static secrets. Make sure that the worker knows if encryption is expected to be enabled so that it can fail out if any of these things are not present or cannot be worked with.
3. Have the worker also accept some template URI for the single-file archive contents, as well as the backup metadata.
4. Have the worker fill in the template with items from the metadata, and then create a document comment block after the closing </html> tag, like this: `<!-- Begin inline MIME --`
5. Create a MIME message header on the next line containing the content type data (`Content-Type: multipart/mixed; boundary="boundary"`)
6. Create a `application/json` MIME section header, and then write the JSON data structure containing a mix of the metadata as well as any of the non-sensitive cryptographic data.
7. Create a new `binary/octet-stream` MIME section header, including the content length.
8. Pump the base64 representation of the ZIP file into this region. Since the BackupService will be the only application that we intend to support reading this block, we don't need to break it up with newlines.
9. On a newline, close the comment block with `-- End inline MIME -->`, followed by a newline.

We won't worry about doing the cryptography bit just yet - we'll just do the raw base64 decoding right now.
This worker should:

1. Take in a URL or handle to a local ZIP file. It might be a file URI, or maybe an nsIInputStream or ReadableStream (which can be sent to workers)
2. Have the worker accept some items from an ArchiveEncryptionState if encryption is enabled. Those things are the public key, the salt, the backup auth key, and the wrapped static secrets. Make sure that the worker knows if encryption is expected to be enabled so that it can fail out if any of these things are not present or cannot be worked with.
3. Have the worker also accept some template URI for the single-file archive contents, as well as the backup metadata.
4. Have the worker fill in the template with items from the metadata, and then create a document comment block after the closing </html> tag, like this: `<!-- Begin inline MIME --`
5. Create a MIME message header on the next line containing the content type data (`Content-Type: multipart/mixed; boundary="boundary"`)
6. Create a `application/json` MIME section header, and then write the JSON data structure containing a mix of the metadata as well as any of the non-sensitive cryptographic data.
7. Create a new `binary/octet-stream` MIME section header, including the content length.
8. Pump the base64 representation of the ZIP file into this region. Since the BackupService will be the only application that we intend to support reading this block, we don't need to break it up with newlines.
9. On a newline, close the comment block with `-- End inline MIME -->`, followed by a newline.

We won't worry about doing the cryptography bit just yet - we'll just do the raw base64 encoding right now.
This method should:

1. Take in a URL or handle to a local ZIP file. It might be a file URI, or maybe an nsIInputStream or ReadableStream.
2. Have the method accept some items from an ArchiveEncryptionState if encryption is enabled. Those things are the public key, the salt, the backup auth key, and the wrapped static secrets. Make sure that the worker knows if encryption is expected to be enabled so that it can fail out if any of these things are not present or cannot be worked with.
3. Have the method use some template URI for the single-file archive contents, as well as the backup metadata.
4. Have the method fill in the template with items from the metadata, and then create a document comment block after the closing </html> tag, like this: `<!-- Begin inline MIME --`
5. Create a MIME message header on the next line containing the content type data (`Content-Type: multipart/mixed; boundary="boundary"`)
6. Create a `application/json` MIME section header, and then write the JSON data structure containing a mix of the metadata as well as any of the non-sensitive cryptographic data.
7. Create a new `binary/octet-stream` MIME section header, including the content length.
8. Pump the base64 representation of the ZIP file into this region. Since the BackupService will be the only application that we intend to support reading this block, we don't need to break it up with newlines.
9. On a newline, close the comment block with `-- End inline MIME -->`, followed by a newline.

We won't worry about doing the cryptography bit just yet - we'll just do the raw base64 encoding right now.
This method should:

1. Take in a URL or handle to a local ZIP file. It might be a file URI, or maybe an nsIInputStream or ReadableStream.
2. Have the method accept some items from an ArchiveEncryptionState if encryption is enabled. Those things are the public key, the salt, the backup auth key, and the wrapped static secrets. Make sure that the worker knows if encryption is expected to be enabled so that it can fail out if any of these things are not present or cannot be worked with.
3. Have the method use some template URI for the single-file archive contents, as well as the backup metadata.
4. Have the method fill in the template with items from the metadata, and then create a document comment block after the closing </html> tag, like this: `<!-- Begin inline MIME --`
5. Create a MIME message header on the next line containing the content type data (`Content-Type: multipart/mixed; boundary="<some generated bounday>"`)
6. Create a `application/json` MIME section header, and then write a JSON structure. For now, it'll just be the metadata. In the future, it'll be the metadata alongside some cryptographic information.
7. Create a new `binary/octet-stream` MIME section header, including the content length.
8. Pump the base64 representation of the ZIP file into this region. Since the BackupService will be the only application that we intend to support reading this block, we don't need to break it up with newlines.
9. On a newline, close the comment block with `-- End inline MIME -->`, followed by a newline.

We won't worry about doing the cryptography bit just yet - we'll just do the raw base64 encoding right now. We also won't worry about hooking this up to the createBackup mechanism just yet.

Back to Bug 1897498 Comment 0