Closed baentsch closed 1 year ago
Where does it run, in the openssl's porject CI?
Do we do the reverse direction of testing? I.e., BoringSSL's CI runs an OpenSSL interop? If so then I think that would suffice.
Do we do the reverse direction of testing? I.e., BoringSSL's CI runs an OpenSSL interop?
No. This highlights the issue: BoringSSL's CI and interop testing is not at the same level as that of OQS-OpenSSL/oqsprovider. We (also therefore) once decided to "demote" it from "OQS-supported" status, but now seem to have reverted that decision in the interest of retaining Chromium demo-only support. This means a "second class/demo-only" BoringSSL can hold back (a whole chain of supported) OpenSSL use cases.
So I'd suggest we either decide to "promote" BoringSSL again to "fully supported" (but then need to first do PRs for that before merging "breaking" liboqs
changes) OR move the "onus of interop testing" to the "second class citizen" BoringSSL: If interop issues happen then, it only breaks CI for BoringSSL and someone may (or may not :) care.
My personal opinion is clear: Do (BoringSSL/OpenSSL) interop testing only in BoringSSL.
My personal opinion is clear: Do (BoringSSL/OpenSSL) interop testing only in BoringSSL.
I think that makes sense
I agree, we are treating BoringSSL as a second-tier project for now, and we don't want its limitations to negatively impact first-tier projects like OpenSSL. So it also makes sense to put the onus of interop testing in BoringSSL.
Given (oqs-)boringssl apparently does not receive the same level of "care and attention" as oqs-openssl111 would it be reasonable to remove the interop-test with it? It always breaks when algorithms get changed in
liboqs
without prior proper downstream preparation.