s2n should have a --list-capabilities commandline flag

[danielsn]

Problem:

Right now, we have various capabilities (e.g. post quantum, which openSSL version, etc ) that can be controlled by compiler defines. Given an s2n binary, its impossible to know what compiler defines it was built under, and which capabilities it has. This makes integration testing hard, and can complicate debugging.

Solution:

add a new flag --list-capabilities which returns a json object listing all of the build time options for s2n, and what values they had.

• Does this change what S2N sends over the wire? no.

• Does this change any public APIs? yes, it adds a new commandline flag.

• Which versions of TLS will this impact?

  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?

[danielsn]

It could also be called --list-build-options

[zz85]

not all s2n is ran from command line, would be good to expose these values via s2n api too.