formalize qrexec RPC semantics

[cfm]

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

• SecureDrop Client (sd-app)
• proxy (sd-proxy)
• GPG (sd-gpg)

People and roles

Problem Statement

Solution impact

Requirements and constraints

Exploration

• Create a serialization format for RPC calls QubesOS/qubes-issues#7084 (comment)
• Design for "remote" qube type QubesOS/qubes-issues#9015
  • qrexec protocol: support for passing source information to the destination QubesOS/qubes-issues#9475

Initial proposal

Selected proposal

---

See also

• [securedrop-log] Evaluate redis alternatives securedrop-client#1719

[cfm]

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
TCP1	→	←	✗	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.

Footnotes

1. From https://github.com/QubesOS/qubes-issues/issues/9037. ↩

[cfm]

I've finished my notes in #1175 (comment) 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?