From the review result:
TLS facilities should either be fully implemented and documented as safe for their advertised use, or unsupported/incomplete security functionality must fail safely and consistently rather than silently degrading security.
Source: Boost review result (conditional acceptance), Boost mailing list, September 2026.
The implementation half is done: opt-in chain and hostname verification landed (#309, #311, #323, #331) and degraded build paths fail closed. But 4l.tls.adoc:443 still warns that set_default_verify_paths() "does not currently load any trust anchors, so it verifies nothing against a real public server". That warning predates #309 wiring it up, while the same page and the https-client example present the call as the verified-safe path. The docs simultaneously claim TLS verification works and that it verifies nothing, which is the exact ambiguity this acceptance condition targets.
From the review result:
Source: Boost review result (conditional acceptance), Boost mailing list, September 2026.
The implementation half is done: opt-in chain and hostname verification landed (#309, #311, #323, #331) and degraded build paths fail closed. But
4l.tls.adoc:443still warns thatset_default_verify_paths()"does not currently load any trust anchors, so it verifies nothing against a real public server". That warning predates #309 wiring it up, while the same page and the https-client example present the call as the verified-safe path. The docs simultaneously claim TLS verification works and that it verifies nothing, which is the exact ambiguity this acceptance condition targets.4l.tls.adocload_verify_file()first-certificate-only NOTE to a security-relevant warning