open-quantum-safe / openssl

UNSUPPORTED Fork of OpenSSL 1.1.1 that includes prototype quantum-resistant algorithms and ciphersuites based on liboqs PLEASE SWITCH TO OQS-Provider for OpenSSL 3
https://openquantumsafe.org/
Other
286 stars 124 forks source link

Remove boringssl interop testing #416

Closed baentsch closed 1 year ago

baentsch commented 1 year ago

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.

christianpaquin commented 1 year ago

Where does it run, in the openssl's porject CI?

baentsch commented 1 year ago

Yes: https://github.com/open-quantum-safe/openssl/blob/5118e6ecd001db20936a753ec5013551ab3a93fb/.circleci/config.yml#L97-L124

dstebila commented 1 year ago

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.

baentsch commented 1 year ago

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.

christianpaquin commented 1 year ago

My personal opinion is clear: Do (BoringSSL/OpenSSL) interop testing only in BoringSSL.

I think that makes sense

dstebila commented 1 year ago

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.