search

open-quantum-safe / liboqs-rust

Rust bindings for liboqs
https://openquantumsafe.org/
Apache License 2.0
120 stars 48 forks source link

expose `OQS_PERMIT_UNSUPPORTED_ARCHITECTURE`, for example as cargo feature #202

Open wucke13 opened 1 year ago

wucke13 commented 1 year ago

I can't build my project for x86 with a musl libc due to https://github.com/open-quantum-safe/liboqs/issues/1442 , and as I see there is no way to trigger the aforementioned CMake option using the rust wrapper, and due to https://github.com/open-quantum-safe/liboqs-rust/issues/190 I can also not substitute the version of liboqs used externally :disappointed:

thomwiggers commented 1 year ago

I'm not sure if it's not better to just wait for a fix for #190 to land upstream...

wucke13 commented 1 year ago

I get the point, this is a bit about failure culture: does liboqs-rust assume that its use of CMake does not contain any errors, and that if there is an error the downstream lib user should have no grip on the matter, or does liboqs-rust enable the user on changing the behavior at the risk of allowing the user to compromise while doing so. I totally get why the second thing first thing sounds better, making a bullet-proof product that can't be used wrong is nice!

However, there is a tradeoff re usability. This and adjacent decisions make it more (one might even say: unnecessarily) complicated to use liboqs, which ultimately could hurt the goals of the oqs project. Please note, I'm no suggesting either way, I'm just pointing out observations (as we already considered replacing liboqs for various friction experienced with the build system).

Just for completeness, I made this to address https://github.com/open-quantum-safe/liboqs/issues/1442, not to fix #190.

thomwiggers commented 1 year ago

Euh right, that's the issue I meant to reference