This repository has been archived by the owner on Jan 5, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
Update readme with metadata format details #6
Merged
Merged
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,4 +2,115 @@ | |
|
||
# securedrop-export | ||
|
||
code for exporting from the securedrop qubes workstation | ||
Code for exporting and printing files from the SecureDrop Qubes Workstation. | ||
|
||
|
||
## Export Archive Format | ||
|
||
Export archive format is defined as a gzipped tar archive whose extension ends with .sd-export. | ||
|
||
### Archive Contents | ||
|
||
Once extracted, the archive will contain two elements: | ||
|
||
`metadata.json` : file containing export metadata, a file containing information about the archive and the export operation | ||
|
||
`export_data`: folder containing the raw files to export | ||
|
||
Example archive structure: | ||
|
||
``` | ||
. | ||
├── metadata.json | ||
└── export_data | ||
├── file-to-export-1.txt | ||
├── file-to-export-2.pdf | ||
├── file-to-export-3.doc | ||
[...] | ||
``` | ||
|
||
### Archive Metadata | ||
|
||
Metadata contains three possible keys which may contain several possible values: | ||
`device` | ||
`device` specifies the method used for export, and can be either a device or a preflight check. See the Devices section below for possible values. It is a required key. | ||
|
||
`encryption_method`: | ||
`encryption_method` is used exclusively when exporting to USB storage. It is an optional key. Possible values are: | ||
luks | ||
|
||
`encryption_passphrase` | ||
`encryption_passphrase` is used exclusively when exporting to USB storage. It is an optional key. It contains an arbitrary string that contains the disk encryption passphrase of the device. | ||
|
||
|
||
Example archive metadata (`metadata.json`): | ||
``` | ||
{ | ||
"device": "disk" | ||
"encryption-method": "luks" | ||
"encryption-key": "Your encryption passphrase goes here" | ||
} | ||
``` | ||
|
||
### Devices | ||
|
||
For all 5 devices described below, there are three generic errors that apply: | ||
|
||
`ERROR_FILE_NOT_FOUND`: No file has been specified or the path is incorrect | ||
`ERROR_EXTRACTION`: Error while extracting the archive | ||
`ERROR_METADATA_PARSING`: The metadata.json file cannot be correctly parsed | ||
`ERROR_ARCHIVE_METADATA`: The metadata failed the check | ||
`ERROR_GENERIC`: An uncaught (unexpected) error somewhere in the script. These should not happen unless the code improperly handles errors | ||
|
||
The list of devices are as follows: | ||
|
||
1. `usb-test` : Preflight check that probes for USB connected devices, that returns: | ||
`USB_CONNECTED` if a USB device is attached to the dedicated slot | ||
`USB_NOT_CONNECTED` if no USB is attached | ||
`USB_CHECK_ERROR` if an error occurred during pre-flight | ||
|
||
2. `disk-test`: Preflight check that checks for LUKS-encrypted volume that returns: | ||
`USB_ENCRYPTED` if a LUKS volume is attached to sd-export | ||
`USB_ENCRYPTION_NOT_SUPPORTED` if a LUKS volume is not attached or there was any other error | ||
`USB_DISK_ERROR` | ||
|
||
3. `printer-test`: prints a test page that returns: | ||
`ERROR_PRINTER_NOT_FOUND` if no printer is connected | ||
`ERROR_PRINTER_NOT_SUPPORTED` if the printer is not currently supported by the export script | ||
`ERROR_PRINTER_DRIVER_UNAVAILABLE` if the printer driver is not available | ||
`ERROR_PRINTER_INSTALL` If there is an error installing the printer | ||
`ERROR_PRINT` if there is an error printing | ||
|
||
4. `printer`: sends files to printer that returns: | ||
`ERROR_PRINTER_NOT_FOUND` if no printer is connected | ||
`ERROR_PRINTER_NOT_SUPPORTED` if the printer is not currently supported by the export script | ||
`ERROR_PRINTER_DRIVER_UNAVAILABLE` if the printer driver is not available | ||
`ERROR_PRINTER_INSTALL` If there is an error installing the printer | ||
`ERROR_PRINT` if there is an error printing | ||
|
||
5. `disk`: sends files to disk: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it would also be helpful to see the errors that can come up for the export There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (and There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. great point @creviera, added those error codes and their description |
||
All files in `export_data` will be sent to disk | ||
`encryption_method` and `encryption_passphrase` specify the device encryption settings | ||
|
||
### Export Folder Structure | ||
|
||
When exporting to a USB drive (using the disk device in metadata.json), the files will be placed on the drive as follows: The root of the USB drive will contain one folder per source, reflecting their source codename in the client. Documents or messages exported will be copied to that directory, preserving the filename from the server. In case a same file is exported twice, a confirmation window replace/rename/abort. | ||
|
||
Example folder structure of USB export drive: | ||
|
||
``` | ||
. | ||
|
||
├── cytotoxic payer | ||
│ ├── 1-cytotoxic-payer-msg | ||
│ │ └── file-to-export-1.txt | ||
│ ├── 2-cytotoxic-payer-msg | ||
│ │ └── file-to-export-2.txt | ||
│ └── 3-cytotoxic-payer-doc | ||
│ │ └── file-to-export-3.doc | ||
├── grandiloquent pasteboard | ||
│ └── 1-grandiloquent-pasteboard-doc | ||
│ │ └── file-to-export-1.doc | ||
└── snug seek | ||
``` | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more question, @emkll. The passage here states that "there are three generic errors that apply" but the succeeding list is five elements long. If I understand correctly, all five "generic" messages can be returned by any of the device type integrations (enumerated below).
If that's the case, perhaps we should say "For all device types (described in detail below), the following standard error types can be returned:". Then, below, instead of "The list of devices are as follows" should be changed to "The supported device types for export are as follows, including the possible errors specific to that device type:".
What do you think?