Add client handshake example
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 170
- Forks
- 43
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 10
Description
The current model in tests/client.c has a workflow that looks like:
- Create a
rustls_connection(which does not involve reading or writing from the socket) - Write unencrypted bytes to the connection
- In a for loop, alternate writes and reads based on the socket state and connection state. The handshake is performed implicitly, followed by the write of the unencrypted bytes.
Some of the C libraries I've seen have a different workflow - they have API's that look like
- Socket connection and TLS handshake (
cr_connect_nonblockingin curl) - API for writing data (
cr_sendincurl,pgtls_writein Postgres libpq/fe-secure.c) - API for reading data (
cr_recvincurl,pgtls_readin Postgres)
It might be helpful to add a second example, or break out the logic in the current example so the handshake is performed separately. Especially since as implemented in vtls/rustls.c, the logic to perform a handshake is not obvious (call the write method with an empty buffer), and there's no explicit "handshake" method in crustls.h
Even if it's the same workflow under the hood, conceptually this might help when porting code that currently exists in C.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the workflow in tests/client.c, then read crustls.h and the handshake-related logic referenced in vtls/rustls.c. Add a second example or refactor the existing example to show the handshake separately, and confirm that the resulting workflow is clear for code ported from other C TLS libraries.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, rust
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100