Make lakers optional and provide options for alternative dependencies

[bkmgit]

Lakers uses Rust and requires a large toolchain to install it. There are cases where this is undesirable. If py-edhoc were revived or Python bindings added to uoscore-uedhoc or to EDHOC-C could these be used as alternatives?

[chrysn]

Even if pyedhoc was revived, the OSCORE implementation depends on the cryptography lib, which itself uses Rust. Does that one work? If so, what can Lakers do to provide the samm convenience? (AIU, it publishes a comprehensive set of binary wheels, and I keep builds up to date where I know PyPI is lacking, eg for Emscripten through pyodide, but maybe I missed some.) If not, is there a drop-in replacement for that to start?

[bkmgit]

Lakers is used in

• https://github.com/chrysn/aiocoap/blob/master/src/aiocoap/edhoc.py
• https://github.com/chrysn/aiocoap/blob/master/src/aiocoap/oscore_sitewrapper.py

Changing cryptography library s probably not worth it.

Could add Python bindings around https://github.com/eriptic/uoscore-uedhoc assuming it has the right functionality as it uses MbedTLS. Could either use ctypes and call it directly or use cffi or nanobind to create bindings.

[chrysn]

There are certainly ways to wrap more libs, but that comes with a maintenance cost, so I need to understand the real problem before jumping to fixes. What maker cryptography easier to handle than Lakers? Both provide bin wheels so local builds should be special cases, and where local builds are needed, Rust needs to be installed for cryptography already.

[bkmgit]

aiocap is used in the test suite for digdoc which is now available in Fedora linux - https://packages.fedoraproject.org/pkgs/digdoc/digdoc/ . Lakers is not packaged in many linux distributions, and each time testing is done, it needs to be rebuilt and the full rust toolchain installed. While it could be packaged, significant effort is required to maintain it as dependencies for rust packages are not shared, and there is no CVE tracking mechanism.

Cryptography is packaged, so cloud builds do not need to rebuild it. For easier testing with Python, pycryptodomex would still be much nicer. For x509 certificates, one could use OpenSSL to avoid Cryptography.

mbedtls python bindings do not seem like they will continue for much longer Synss/python-mbedtls#118

uoscore-uedhoc seems to use version 3.1.0 of mbedtls

Checking pyedhoc dependencies.

[chrysn]

Maintaining additional EDHOC backends would add a significant maintenance effort (even beyond the initial porting). If there's a runtime reason, that's fine, but as long as we're just talking of some CI time spent and the alternative is spending person-time, that'd be a huge lot of CI time to warrant starting spending person-time.

What is keeping you from using the provided Python wheels?

[bkmgit]

Have found libedhoc which is in C. Will investigate adding Python bindings.

[chrysn]

I appreciate the enthusiasm, and I'll try to give any PR a better review than is my track record so far, but I still don't quite understand the trade-offs here:

The issue with lakers is that it's not packaged in Fedora. Fedora has the build infrastructure for Rust crates. So there are three paths forward:

• Have the lakers dependency built through pip as part of the packaging. Not the cleanest, and that'll slow down every build, of aiocoap, but that's just CI time.
• Package lakers in Fedora. I don't know how Fedora packages work, but I've looked into the Debian packaging side, and it's not a big deal. (Most metadata is already there, so packaging a crate for Debian is mainly about acknowledging that the generated copyright file is OK).
• Add a new backend such as libedhoc (which AIU is also not packaged in Fedora, and having packaged C libraries for Debian, I assume by analogy that it is no easier than packaging Rust libraries). On top of the packaging effort, this is a nontrivial extension to aiocoap (like, might easily take a week to become a drop-in replacement, and that's a low guess), and needs continuous maintenance as Lakers gains new features.

Adding Python bindings to libedhoc and putting them in here sounds like the worst option here by far -- where am I wrong?