Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace well_known_endpoints integration test with a hyper test #4837

Open
goatgoose opened this issue Oct 10, 2024 · 0 comments
Open

Replace well_known_endpoints integration test with a hyper test #4837

goatgoose opened this issue Oct 10, 2024 · 0 comments

Comments

@goatgoose
Copy link
Contributor

Problem:

The well_known_endpoints test performs TLS handshakes with a list of well-known endpoints, which ensures that the s2n-tls client remains compatible with well-known TLS servers.

However, this integration test is unique in that it doesn't require any of the other TLS providers. It just runs s2nc against all of the endpoints. A better place for this test might be s2n-tls-hyper, which would also allow for the s2n-tls hyper client to be tested against real endpoints over the network.

Solution:

Replace the well_known_endpoints integration test with an s2n-tls-hyper test.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

  • RFC links: Links to relevant RFC(s)
  • Related Issues: Link any relevant issues
  • Will the Usage Guide or other documentation need to be updated?
  • Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
    • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
    • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants