From b8d5eb06a51ed4747fc564ea6c17c505d9e50573 Mon Sep 17 00:00:00 2001 From: Matt <47545907+SoundMatt@users.noreply.github.com> Date: Sat, 22 Aug 2026 14:06:18 -0700 Subject: [PATCH] =?UTF-8?q?rewrite(phase8):=20batch=20B=20=E2=80=94=20cont?= =?UTF-8?q?ent-parity=20audit=20(tsn/powerstate/faultinject/ratelimit/mdns?= =?UTF-8?q?/authz/relay/bridges)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Part of the v3.0.0 ground-up rewrite (cpp-RCP #129, ROADMAP.md Phase 17), branch rewrite/v3-from-c-rcp. Phase 8 (remaining modules), batch B of 2: tsn, powerstate, faultinject, ratelimit, mdns, authz, relay/relay.hpp, restbridge/grpcbridge -- all already fully implemented+tested from an earlier untracked pass; this batch is a content-parity audit against c-RCP, not a rewrite. ## Findings, per module - tsn.hpp: already equivalent within a documented architectural divergence (c-RCP wraps a full AVTP transport + raw-frame priority classifier; cpp-RCP exposes a primitive apply_priority() called with an already-known RequestCategory) -- pre-documented in-header, no action. Catalog observation only (c-RCP's REQ-TSN-007/008 have no cpp-RCP analog, by design) -- left untouched, Phase 6 is closed. - powerstate.hpp: no new findings beyond the 8 already-filed pending gaps from Phase 6 batch 13 (REQ-PWRMODE-004/012/017/019/021/022/ 026/027) -- confirmed NOT re-litigated. Confirmed wakeup.hpp (not powerstate.hpp) carries the actual SleepCMD/WakeUp wire codec equivalent to c-RCP's ep_wakeup.h -- a layering difference, not a missing capability. No changes. - faultinject.hpp: capability-equivalent (Drop/Slow/Error/Timeout, count-limited rules). Notably its pick_rule() already fixes a real use-after-free/data-race an earlier revision had, documented in-file as cpp-RCP-D6 -- arguably more correct than c-RCP's own mechanism. No action. - ratelimit.hpp: capability-equivalent (token bucket, safety-tag exemption, per-domain keying). Bootstrap/refill semantics match exactly. No action. - mdns.hpp: capability-equivalent (Discoverer/Announcer, StaticDiscoverer, make_instance_name). One cosmetic-only divergence (hex case, service type string) -- not a wire-interop requirement since mDNS records are self-contained. No action. - authz.hpp: genuine capability-granularity gap found, documented in-file rather than ported -- c-RCP keys policy entries on an opaque request_type byte (letting a policy distinguish read vs write within one request kind); cpp-RCP's RequestCategory taxonomy is coarser and cannot express that distinction. Pre-existing since v2.11.0, already justified at length in the header's own comment, and changing it would break the already-tested PolicyEntry/permit() contract -- out of this batch's authority. Documented as a known granularity gap for a possible future targeted fix, not force-fit here. - relay/relay.hpp: confirmed structurally distinct from adapt.hpp (relay.hpp is the protocol-agnostic Channel/Context/Node abstraction; adapt.hpp is the RCP-specific wiring on top, already covered by Phase 6 batch 12). c-RCP's own relay.h header states outright it is "a pure-C port of the same subset cpp-RCP's include/relay/relay.hpp exposes... not a full RELAY binding" -- cpp-RCP's version is the reference here, confirmed full parity (superset, even -- templated Channel vs one concrete type). No action. - restbridge.hpp/grpcbridge.hpp: both compile-time interface stubs on both sides (no backend linked, every call returns not-supported). c-RCP's own header comments confirm they mirror cpp-RCP's stub behavior. Config shapes and defaults match exactly. No action. ## Verification Independently re-verified: confirmed the c-RCP relay.h "pure-C port of cpp-RCP's own relay.hpp" claim, the restbridge.h "mirrors cpp-RCP's own stub" claim, and the faultinject.hpp cpp-RCP-D6 use-after-free-fix comment all directly against source -- all accurate. Full tree rebuilt from scratch: 0 errors, 0 warnings, 58/58 ctest suites pass (100%). include/rcp/authz.hpp: +17 lines (comment only, zero behavior change). No other files touched. Co-Authored-By: Claude Sonnet 5 Signed-off-by: Matt <47545907+SoundMatt@users.noreply.github.com> --- include/rcp/authz.hpp | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/include/rcp/authz.hpp b/include/rcp/authz.hpp index 93a12bd..a6de4c5 100644 --- a/include/rcp/authz.hpp +++ b/include/rcp/authz.hpp @@ -101,6 +101,23 @@ struct PolicyEntry { std::unordered_set endpoints; // Request kind: empty = any kind. + // + // Phase 8 batch B audit note (c-RCP parity): c-RCP's rcp_authz_policy_allow() + // keys this axis on a caller-supplied, deliberately opaque uint8_t + // request_type byte (see c-RCP's authz.h file header) rather than on + // request::RequestCategory — for a Standard request that byte is + // conventionally acf.h's rcp_acf_op_t (RCP_ACF_OP_READ/_WRITE), so a + // c-RCP policy entry can distinguish "may read but not write" within a + // single RequestCategory::Standard request, a distinction this axis + // cannot express (every Standard request — read or write — collapses to + // one RequestCategory::Standard value here). This is a deliberate, + // pre-existing choice (present since this header's own v2.11.0 rebind, + // not introduced by this audit): RequestCategory is "already the single + // taxonomy" this codebase keys every other request-kind axis on (see + // this file's header comment), and changing it to an opaque byte would + // be a breaking change to this already-tested PolicyEntry/permit() + // contract. Left as a known, documented granularity gap rather than + // ported in this batch. std::unordered_set kinds; };