Basil Hess

> I come across this PR and I have a few questions: > > 1. Can we merge the MAYO_*_opt into a single folder, so it's easier to review? >...

> Some platforms I don't see include > > * ubuntu on arm (aarch64) > * Z (s390x) > And we'd _love_ to streamline our CI to one system Moving...

> * There is an unofficial version of github action runner as mentioned above, which seems current, and now supports (experimental...!) s390x. There is hope this could get integrated by...

Thank you for picking this up @praveksharma ! The environment is: OS: Ubuntu 22.04.3 LTS OpenSSL version 3.0.2 Compiler version used: GCC 11.4.0 Build variables used: -DCMAKE_BUILD_TYPE=Debug -DOQS_ENABLE_TEST_CONSTANT_TIME=ON liboqs version:...

The PR is updated and now includes MAYO_5, handling it the same way as the other schemes with large stack usage. Not sure yet about the two failing macOS builds...

> Thanks for this work, @bhess! All of my comments are resolved and the [oqs-provider integration tests](https://github.com/open-quantum-safe/oqs-provider/actions/runs/9870371399/job/27255963431) are passing. Thanks for the review @SWilson4 !

> Thanks for this integration, @bhess. Would it be conceivable to use an algorithm naming convention a bit more in line with what we've been using so far, i.e., either...

> I'll update this PR and [open-quantum-safe/oqs-provider#413](https://github.com/open-quantum-safe/oqs-provider/pull/413). Done

> Sorry for the merge conflicts introduced by #1832, @bhess. I think it's a straightforward resolution: just move the AES callback structure updates to the new [`aes_ops.h`](https://github.com/open-quantum-safe/liboqs/commit/26feef2e8a7863cc4f479e3ac387443beec06791/src/common/aes/aes_ops.h) file. Thanks for...

Thanks for the review @baentsch ! > * Could you please trigger a re-run without "skip ci" so the latest code in this PR gets tested there? Done - the...