[ralyodio]

Job offers went to the gossip topic c0mpute/jobs/<workload> with the whole job inline. Every peer and relay on the topic could read every prompt, transcript and URL. Inputs and results were plaintext chunks, and anyone could fetch them by the hash that the offer and the receipt published. This PR makes every job end-to-end encrypted between the buyer and the one worker that wins. The design is in dips/0032-e2e-encrypted-jobs.md.

What changes on the wire

• Offer: no spec. It carries a public spec (a per-workload allowlist of small scalars such as model, engine, voice, width/height, frame range and base_model, plus power-of-two size buckets), a fresh buyer X25519 key, and a salted commitment as spec_hash. required_capabilities gains c0mpute:e2e:v1, so pre-e2e workers never bid.
• Bid: carries a fresh worker X25519 key, signed by the worker's libp2p ed25519 identity. The buyer checks the signature against the bidder's peer id before it seals anything.
• Accept: carries no spec. The winner fetches the sealed spec over request-response (c0mpute.job.payload.v1). The buyer serves it only to the noise-authenticated winner, and only while the auction is open.
• Crypto: X25519, then HKDF-SHA256, then AES-256-GCM. Keys and associated data are bound (length-prefixed) to job id, workload, both peer ids and both keys. The winner checks the commitment and that the public spec matches the sealed spec. It then re-runs the workload's own filter on the whole spec before running the job; on any failure it sends a Failed receipt.
• Results: sealed to the buyer before they are stored. This covers every runner, render frames, text adapters and answers, gameserver results and inference. gateway_util::fetch_result / fetch_result_to_file open them with the auction's result key. Receipts name the ciphertext hash.
• Inputs: STT audio, img2vid images, OCR documents, .blend files, training corpora and chat adapters are stored sealed, each under its own key, and the key rides inside the sealed spec. The winner decrypts inputs only in memory or in the job dir. A sealed .blend stays sealed in the cache. A sealed adapter is never put in the adapter cache. spec_ref (large specs stored as plaintext chunks) is no longer used, because sealed specs travel point to point.
• Confidential option: a with_confidential(true) auction requires c0mpute:confidential. The offer carries an attest nonce. The report data binds the TEE to the sealed-to key. AttestationVerifier / AttestationProvider hooks fail closed. A concrete SEV-SNP/TDX producer and verifier are deferred.
• Compatibility: workers still serve plaintext offers for this one release. C0MPUTE_REJECT_PLAINTEXT_OFFERS=1 refuses them now.

What the winning worker still sees

The plaintext of the job it computes on. For sensitive work, use private mode or the confidential requirement. Observers still see metadata: the public spec, price, timing, bidders, sizes, and text-train progress events.

Tests

• Crypto unit tests: keys derive the same on both sides; a wrong worker cannot open; tampering, truncation, a moved job, a wrong commitment and low-order keys are all rejected; streamed files; public views carry no SECRET for any workload.
• Dispatch: an e2e bid refuses plaintext and downgraded accepts.
• tests/e2e_jobs_e2e.rs: a buyer, two workers and a passive gossip subscriber, across 15 workloads. The passive node sees no plaintext in any offer, bid, accept or receipt. The loser is refused the sealed spec. Result and input chunks fetched by the passive node are ciphertext. The buyer opens the results.
• Existing auction, private, large result/input, ocr, render, text train (incl. replicas), workflow, inference, video, gameserver, temporal and crowdgpt e2e tests all pass. ads_e2e fails on dev2 only because the hosting disk floor refuses replicas at 46 GiB free; that is environmental and unrelated. Gossip tests need C0MPUTE_DISABLE_MDNS=1 on dev2's busy LAN, the same as before.

🤖 Generated with Claude Code

[github-actions]

ThreatCrush Security Scan

13 finding(s)

HIGH/CRITICAL: 1 | MEDIUM: 8 | LOW: 4

Severity	Rule	Location
HIGH	js-ssrf-outbound-request	apps/web/public/sw.js:24
MEDIUM	js-unescaped-html-sink	apps/web/src/app/blog/[slug]/page.tsx:53
MEDIUM	js-unescaped-html-sink	apps/web/src/app/layout.tsx:89
MEDIUM	sh-remote-script-execution	scripts/dev-setup.sh:25
MEDIUM	sh-eval-expansion	scripts/dev-setup.sh:35
MEDIUM	sh-remote-script-execution	scripts/install.sh:181
MEDIUM	sh-remote-script-execution	scripts/install.sh:206
MEDIUM	sh-remote-script-execution	scripts/install.sh:399
MEDIUM	sh-remote-script-execution	scripts/install.sh:441
LOW	py-ssrf-outbound-request	examples/business-strategist-agent/chat.py:37
LOW	py-ssrf-outbound-request	examples/business-strategist-agent/train.py:54
LOW	secret-generic-credential	node/crates/c0mpute-core/src/webhook.rs:1171
LOW	py-path-traversal	node/crates/c0mpute-core/tests/fixtures/fake-infernet-text:29

Snippets are redacted; ThreatCrush never prints matched credential material.