search

freedomofpress / securedrop-workstation

Qubes-based SecureDrop Journalist Workstation environment for submission handling
GNU Affero General Public License v3.0
141 stars 43 forks source link

formalize qrexec RPC semantics #1175

Open cfm opened 1 month ago

cfm commented 1 month ago

After freedomofpress/securedrop-engineering#82 and freedomofpress/securedrop-client#1777, this is a stub proposal to suggest that we could formalize an RPC convention of JSON, CBOR, etc., over qrexec, such that:

  1. the standard input is a single-line (e.g.) JSON "request" object; and
  2. the standard output (exit code 0) is either (a) a single-line (e.g.) JSON "response" object or (b) a "raw" lower-level blob or stream;
  3. the standard error (any other exit code) is a single-line (e.g.) JSON error object.

Formalizing this would let us reuse rather than reinvent it, possibly including a minimal Python and/or Rust (a) library for the caller and (b) framework for the post-qrexec entrypoint.

Affected components

People and roles

Problem Statement

Solution impact

Requirements and constraints

Exploration

Initial proposal

Selected proposal

See also

cfm commented 1 month ago

Notes from discussions at the Qubes OS Summit this week:

Type stdin stdout stderr rc We should it use for... ...with... ...for example...
Process → ← ← ← Local, blocking RPC UNIX-process semantics Split GPG
Socket → ← ✗ 0 Local, nonblocking streaming ??? freedomofpress/securedrop-client#1719
TCP[^1] → ← ✗ 0 Remote/networked proxying Transparency/agnosticism to the underlying wire protocol securedrop-proxy v3 (HTTP)

It's still an open question what serialization to use: that is, whether qrexec should insert a standard serialization between its call semantics (process, socket, TCP) and the callee's qrexec-oblivious I/O channels.

[^1]: From https://github.com/QubesOS/qubes-issues/issues/9037.

cfm commented 1 month ago

I've finished my notes in https://github.com/freedomofpress/securedrop-workstation/issues/1175#issuecomment-2366807756 and updated the top of the ticket to reflect the following shift in my thinking since the Qubes OS Summit. Where I was originally focused on the input/output de/serialization (JSON, CBOR, etc.), I now think the most important question for us to consider here is whether we always want UNIX-process semantics for our qrexec calls. For example, in freedomofpress/securedrop-engineering#82, if we're fundamentally concerned with HTTP and especially REST endpoints upstream, why bother with process semantics (standard input, output, error; return code) when we could just do HTTP via a socket- or TCP-based qrexec service?