factor out export "protocol" into common package

[cfm]

securedrop-client/client/securedrop_client/export_status.py

Lines 9 to 14 in 0555520

	class ExportStatus(Enum):
	"""
	All possible strings returned by the qrexec calls to sd-devices. These values come from
	`print/status.py` and `disk/status.py` in `securedrop-export`
	and must only be changed in coordination with changes released in that component.
	"""

This suggests to me that we need a package securedrop-export-common, on which both securedrop-client and securedrop-export depend.

Originally posted by @cfm in #1777 (comment)

[legoktm]

Agreed that we need a better way to share across components but if this is just one file I'd probably look for an easier way to duplicate stuff, like symlinks vs the overhead of a shared package.

[cfm]

On Wed, Feb 21, 2024 at 03:03:29PM -0800, Kunal Mehta wrote: Agreed that we need a better way to share across components but if this is just one file I'd probably look for an easier way to duplicate stuff, like symlinks vs the overhead of a shared package.

I leapt for the "common package" option because intuitively there's an implicit versioned protocol here. But I think you're right that it may be both adequate and simpler to regard it just as shared code.

[legoktm]

I leapt for the "common package" option because intuitively there's an implicit versioned protocol here.

I think you're absolutely right on this, and we have the same pattern in proxy v2 that's just less obvious because it's in two different languages:

/// Serialization format for non-streamed requests
#[derive(Serialize, Debug)]
struct OutgoingResponse {
    status: u16,
    headers: HashMap<String, String>,
    body: String,
}

@dataclass(frozen=True)
class JSONResponse:
    data: dict
    status: int
    headers: Dict[str, str]

(not identical, but pretty close)

But I think you're right that it may be both adequate and simpler to regard it just as shared code.

To set up the shared package we'd:

1. create the new Python component: setup.py, etc.
2. Set it up as a path dev dependency: https://python-poetry.org/docs/dependency-specification/#path-dependencies
3. modify the build stuff to install it into the virtualenvs of client + export (I don't think we'd end up with a new Debian package)

If we think making it easier to share code will result in more code being shared then setting up the infrastructure for it makes sense, otherwise if it's just one or two files I think just having a test to keep them in sync or symlinks is simpler.

In Rust we'd get to skip step 3 since all the dependencies are automatically compiled in and I'd definitely want to see us share e.g. serde structs to have nicer type safety on both sides.

[legoktm]

client/securedrop_client/utils.py and export/securedrop_export/directory.py have a lot of duplicated code too (which was the intent behind the now-archived secure-fs library).