DDS-Security: identity-bound participant GUID computed by SecurityProfile::from_files is never applied to the runtime participant, so two secured participants can never complete discovery

[swarm59]

During zero DDS evaluation we have found a possible security issue described in the annexed report.
BUG-ZERODDS-001-UPSTREAM-REPORT.md

[SandraK82]

Thank you again, @swarm59, for tracing this across the PKI, security-profile, runtime, and participant-creation layers. You were exactly right: the identity-adjusted GUID prefix was computed correctly, but the public Rust participant path did not actually apply it to the participant announced on the wire.

SecurityProfile::from_files stored the §9.3.3-adjusted GUID, while RuntimeConfig::with_security_bundle initially copied only the security gate. DomainParticipant::new_with_runtime therefore fell back to a random GUID prefix. A conforming peer can reject that participant because the GUID in c.pdata is not derived from the identity certificate, preventing secured discovery from completing.

This is fixed on main in 927d4af. The adjusted prefix now travels from SecurityProfile through RuntimeConfig into participant creation, while the unsecured participant path remains unchanged.

Your report also exposed a deeper architectural problem: the security GUID requirement was enforced only by convention and differed between entry points. The C API already passed an adjusted prefix in one path, while the public Rust API did not, and a caller constructing RuntimeConfig manually could still start a secured participant with an unrelated prefix.

The follow-up therefore added a fail-closed invariant at the common DcpsRuntime::start boundary. Whenever security is active, the prefix used to start the participant must match the identity-derived prefix in the runtime configuration. A missing or mismatched value now returns NotAllowedBySecurity instead of allowing a participant to start successfully and then fail silently during a peer handshake. The secured FFI path and its tests were updated to pass through the same invariant, so the public Rust API, C API, bridges, and direct runtime callers can no longer bypass it.

The regression coverage uses real OpenSSL identities and signed governance/permissions material, constructs participants through the public Rust factory path, independently recomputes the §9.3.3 prefix, verifies the prefix announced by the runtime, and confirms that two secured participants complete discovery. Separate tests cover unsecured, missing-prefix, mismatched-prefix, matching-prefix, and secured-FFI construction cases.

One evidence boundary is worth stating explicitly: these regressions prove the public ZeroDDS API wiring and the on-wire §9.3.3 value. We are not presenting the public GitHub Actions run alone as a fresh live CycloneDDS or Fast DDS handshake for this exact pure-Rust construction path; that remains separate cross-vendor interoperability evidence.

The complete public main build, including the security GUID wiring and fail-closed guard tests, is green:
https://github.com/zero-objects/zero-dds/actions/runs/30556000574

I am closing this discussion as fixed. If a secured participant created through current main still announces a GUID that does not match its identity certificate, or if a foreign peer rejects it for that reason, please let us know here — we will be very happy to reopen the discussion and investigate the captured handshake with you.

Your continued careful review has helped us turn a single missing assignment into an invariant that now protects every secured participant-creation path.