Add chain verify callback example - #625
Open
julek-wolfssl wants to merge 4 commits into
Open
Conversation
Member
Author
|
Depends on wolfSSL/wolfssl#11367 |
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The new example has confirmed correctness issues (undefined symbol, resource cleanup leaks, and unsafe thread/library cleanup ordering) that can break builds or cause runtime hazards.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds a new TLS client example demonstrating wolfSSL’s chain verify callback mechanism to support an external “root of trust” (e.g., an HSM-like trust service), and documents how to build/run it.
Changes:
- Added
client-tls-chainverifycbexample implementing deferred handshake verification viaCHAIN_VERIFY_WANT_Eand a background “trust service” thread. - Updated
tls/README.mdwith build/run instructions and expected outputs for the new example and its demo switches. - Updated build/ignore plumbing (
tls/Makefile,.gitignore) for the new example binary.
File summaries
| File | Description |
|---|---|
| tls/README.md | Documents the new chain verify callback example and how to build/run it. |
| tls/Makefile | Ensures the new example is built with -pthread. |
| tls/client-tls-chainverifycb.c | New client example implementing deferred verification via chain verify callback and a trust-service thread. |
| .gitignore | Ignores the newly built client-tls-chainverifycb binary. |
Review details
Suppressed comments (1)
tls/client-tls-chainverifycb.c:183
- If
pthread_create()fails,service_start()returns without cleaning up the mutex/cond or freeingsvc->anchor, which leaks resources and leavesservice_stop()unsafe if it were called later. Clean up before returning.
pthread_mutex_init(&svc->lock, NULL);
pthread_cond_init(&svc->cond, NULL);
if (pthread_create(&svc->thread, NULL, service_thread, svc) != 0) {
fprintf(stderr, "trust service: cannot start thread\n");
return -1;
}
- Files reviewed: 3/4 changed files
- Comments generated: 4
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
A TLS client whose root of trust lives outside wolfSSL. No CA is loaded into the context; a chain verify callback hands the server's certificates to a trust service on its own thread, standing in for an HSM that holds the anchors, and defers the handshake with CHAIN_VERIFY_WANT_E until the service has a verdict. Switches show the handshake failing with no callback installed and with the service rejecting the chain. Requires wolfSSL built with --enable-chain-verify-cb.
The example needs --enable-chain-verify-cb, which the tls profile did not carry, so client-tls-chainverifycb built as the stub that prints "wolfSSL was built without --enable-chain-verify-cb" and nothing ran it. Add the flag, and a pair entry that runs it against server-tls. The flag only defines WOLFSSL_CHAIN_VERIFY_CB. WOLFSSL_ASYNC_IO is already on in this profile, so nothing else in tls/ is affected. server-tls presents ../certs/server-cert.pem on port 11111, which the client's default anchor ../certs/ca-cert.pem issued, so the pair needs no arguments beyond the host.
julek-wolfssl
force-pushed
the
chain-verify-cb
branch
from
September 8, 2026 12:39
ab84a89 to
eb6d9c9
Compare
The trust service thread calls wolfSSL, so joining it after wolfSSL_Cleanup() could tear down library state the thread was still using. Stop the service first. Three error paths alongside it: - Size the anchor file before allocating for it. A ftell() of -1 became a SIZE_MAX malloc, and the read failure path returned without freeing. - Destroy the mutex and condition variable and free the anchor when pthread_create() fails, so a service that never started leaves nothing behind. - Keep the socket's existing flags when setting O_NONBLOCK, and fail if either fcntl() does, rather than running blocking without saying so.
--enable-chain-verify-cb reached wolfSSL master in wolfSSL/wolfssl#11367 and no release carries it. configure exits 1 on an unrecognized --enable-*, so carrying the flag in the shared tls profile failed that whole directory on the stable tag rather than just skipping the one example. Give it its own profile and its own entry, pinned to master with wolfssl_ref, the way pkcs7-signeddata-stream already is. The other 22 tls targets keep testing the released library. The entry builds only the two binaries its pair needs, since the tls entry builds the rest against both refs already. wolfssl-matrix built every profile for every ref and then seeded whatever pins were missing, so a profile no unpinned entry uses was still built for refs its flags predate. Build the (profile, ref) pairs entries actually ask for instead, which covers the pinned ones and drops the impossible ones.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a TLS client example demonstrating an external root of trust: no CA is loaded into the wolfSSL context, and a chain verify callback instead hands the server's certificate chain to a trust service running on its own thread (standing in for an HSM holding the anchors). The handshake is deferred with
CHAIN_VERIFY_WANT_Euntil the service returns a verdict.--enable-chain-verify-cb.