search

xvzcf / tls-interop-runner

Interoperability testing of TLS implementations.
Other
10 stars 13 forks source link

Adding BoringSSL runner. #49

Closed xvzcf closed 3 years ago

chris-wood commented 3 years ago

@xvzcf is there a reason why we can't get the tool files from the cloned version of BoringSSL, rather than bake them in here?

xvzcf commented 3 years ago

The files here are the tool sources with a decent amount of code removed and some modifications made (the runner returns 64 when a testcase is unsupported for example).

The reason for doing this was to get fine grained control over the setup, teardown, and validation for each testcase; on the client side dc testcase for example, this check is run after the connection is completed.

As we start coming up with more complicated testcases, it seems like the flexibility we get from calling library code directly would make things easier as opposed to having to conform to/extend the tool command line API.

dmcardle commented 3 years ago

The goal is to use only public APIs, right? I think this is the right way to do it. BoringSSL's client/server command-line flags have no stability guarantee, so it makes sense to maintain your own.

chris-wood commented 3 years ago

This LGTM then 👍 When BoringSSL adds ECH support for draft-10, we can update the runner to handle that test case, too.

xvzcf commented 3 years ago

Sounds good.

I also think there's also a broader discussion here: currently the Dockerfile pulls my personal branch which has the latest DC spec implementation, but for ECH we'll be using master. To get both DC and ECH support, do I rebase my branch off the BoringSSL master when ECH draft-10 goes in? Do I build binaries from both branches and build two runners? Or do I create two Dockerfiles representing two slightly different BoringSSL endpoints (one based on my branch and one based on master) and modify the cmd/runner code accordingly?

I'm leaning towards some sort of separation, since the code in master is more thoroughly reviewed and tested than the one in my branch, but I'm not yet sure what the cleanest way of going about this would be.