mirror of
https://github.com/logos-co/logos-cpp-sdk.git
synced 2026-09-01 10:11:10 +00:00
Dario Gabriel LipicarandClaude Opus 5
b9d7641fae
Phase C1. A Qt-free, header-only wrapper over the three trust-root lp_* calls A3 added, so capability_module can become an ordinary universal module instead of a hand-written Qt plugin reaching into TokenManager directly. Deliberately FREE FUNCTIONS, not a LogosModuleContext seam as the plan sketched. The grant is process-global per IMAGE (host binary and module cdylib each link their own logos-protocol, so each has its own grant state and its own TokenManager), so the gate lives in the caller's own image and there is nothing per-instance to inject; a context seam would imply the privilege is a property of one impl object, which it is not. It is also markedly cheaper: a seam would need a new module-impl C ABI export plus lockstep changes in BOTH codegen paths (the Qt provider glue and the cdylib wrapper). constantTimeEquals lives here rather than in each caller: the natural spelling (a == b) leaks the matching-prefix length through timing, and a trust root comparing tokens with == is the exact bug this file exists to prevent. Ported from capability_module's own implementation to std::string. Two things the tests caught that reading had not: * lp_inform_module_token_to takes SIX arguments (client, auth_token, origin_module, module_name, token, timeout_ms), not the three I first wrote. The wrapper now mirrors it exactly, with the protocol's own default-timeout semantics documented. * sdk_tests compiles against logos_headers alone, which carries no protocol include path. It now resolves logos_protocol.h from LOGOS_PROTOCOL_ROOT, accepting either the source layout (cpp/) or a package layout (include/) and failing loudly on neither, rather than hard-coding the one in use today. The suite deliberately does NOT link logos-protocol: the lp_*-calling wrappers are `inline` and never ODR-used by these tests, so no protocol symbol is referenced. That is itself the assertion — the veneer must not drag the protocol library into a header-only consumer. A future test that calls one will fail to LINK rather than silently pull it in. Also documents a real gap found while writing it: lp_token_get performs NO host-service check, so "token_registry" gates ENUMERATION only. The plan claims that service covers `lp_token_get(any)`; it does not. Flagged at the call site rather than papered over — if lookup should be gated, the gate belongs in lp_token_get. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>