Spencer Wilson

> You may also consider adding "-DOQS_USE_SHA3_OPENSSL=ON" to [this CI test](https://github.com/open-quantum-safe/liboqs/blob/3e34ed18548d504aadc0edf0fac53af5f664a7be/.github/workflows/linux.yml#L90) which is using 3.0.2 and maybe some other "OpenSSL master" test to test-drive the OpenSSL SHA3 code more regularly...

I tried running the tests with the memory sanitizer turned on after creating #1680. The build was intensive, and the tests failed _very_ loudly. Interestingly enough there were quite a...

Closing this as resolved via #1531.

It seems like this feature will be mostly "free" in the [soon-to-be-integrated](https://github.com/open-quantum-safe/liboqs/pull/1626) ML-KEM (formerly known as Kyber)—we would just have to add the necessary OQS API functions to expose the...

> > we would just have to add the necessary OQS API functions to expose the functionality > > OK for ML-KEM. What for other KEMs? Shall they simply throw...

Given that we now have CI builds for both Android and iOS, I think this issue can be safely closed. @dstebila @baentsch Feel free to reopen if you have objections.

It looks to me like this will be resolved if/when PQClean integrates the upstream Sphincs+ licence changes and we run `copy_from_upstream`. Assuming the PQClean update is straightforward, it shouldn't require...

Is it safe to close this issue as well, @baentsch?

I like this idea, and I think it could help us delineate the boundary between "production" and "experimental" versions. A "production" build of the library could include only those implementations...

> @dstebila : What was the reason to add this issue to the 0.10.0 milestone? OK to postpone this to 0.11.0 such as to bring the 0.10.0 milestone to completion/"RC-readiness"?...