Audit current MbedTLS 4.1 integration
Workflow status is tracked in GitHub: https://github.com/emulebb/emulebb/issues/21. This local document is retained as an engineering spec/evidence record.
Summary¶
The earlier REF-028 framing said current main still needed an upgrade from a
MbedTLS 3.x pin to MbedTLS 4.0. That is stale. Current workspace dependency
topology uses the emulebb-mbedtls fork on mbedtls-v4.1.0-emule, with
TF-PSA-Crypto present as part of that fork.
There is no selected MbedTLS upgrade for beta 0.7.3. This item stays deferred
as a future audit/hardening note for the current 4.1 integration only.
Current State¶
- Current
mainstill linksmbedtls.lib,mbedx509.lib, andtfpsacrypto.lib. - Current app code still uses MbedTLS for WebSocket/HTTPS and related certificate/TLS surfaces.
- The active dependency status document records MbedTLS and TF-PSA-Crypto as current/no-action dependencies.
- Older docs that say MbedTLS was removed, or that the workspace still needs a
3.x-to-4.x dependency upgrade, are historical/stale for current
main.
Deferred Audit Topics¶
- Re-check
MBEDTLS_ALLOW_PRIVATE_ACCESSusage and decide whether it remains an acceptable compatibility bridge. - Keep the current static-library integration model unless a later explicit dependency-policy pass changes it.
- Revisit TLS 1.3 configuration only as a future protocol/web hardening task, not as beta release scope.
Acceptance Criteria¶
- [x] Stale MbedTLS 3.x-to-4.x upgrade framing is removed from the active backlog.
- [x] Active dependency docs record the current MbedTLS 4.1-era fork as the selected dependency.
- [ ] If reopened later, private-access usage is audited against the current MbedTLS public API.
- [ ] If reopened later, any TLS 1.3 configuration change is handled as a focused behavior change with targeted proof.