wolfSSL support added

[Flole998]

This is the first step to add support for wolfSSL in Rust on RIOT-OS. This has been tested using DTLS 1.3 and using SHA256. There is a work-in-progress wrapper that this sets the base for.

[chrysn]

Does it make sense to expose WolfSSL, and if yes, wouldn't the wrapper best be RIOT-independent? (Although even a indep. wrapper needs this). Reason I ask are DTLS sockets: RIOT abstracts DTLS into those, and has credman which'd be interesting to wrap, but I don't see where direct WolfSSL wrappers are helpful (yet?).

[Flole998]

wolfSSL does much more than just DTLS.

Also the DTLS sockets aren't completely abstracted (yet), the way I understand it there's still a need to open and configure the socket with wolfSSL and sock_tls/sock_dtls then only takes care of the read/write.

[chrysn]

What setup steps are there that are not done via credman? For the WolfCrypt parts, may libcose be a good place to wrap them?

[Flole998]

There are several (optional) things that credman doesn't do, especially when it comes to using wolfSSL with a crypto IC so the keys aren't stored in RIOT itself but in a secure storage device. Also things like setting ciphersuites don't seem to be supported at the moment.

Is there any downside of wrapping something that can also be accessed by sock_tls/credman?

[chrysn]

Is there any downside of wrapping something that can also be accessed by sock_tls/credman?

Having a way to create WolfSSL functionality is fine. The direction I'm worried about is that that'd happen in riot-wrappers (which admittedly this PR doesn't necessitate, but it'd be an obvious way this could continue) -- and doing all of that for RIOT alone might be difficult to do long-term.

The way I think WolfSSL should be wrapped is:

• One crate should safely wrap WolfSSL things independently of RIOT, depending on a build-time selection of either:
  • a wolfssl-sys crate that works on the host system like any other -sys (say, openssl-sys), or
  • a riot-sys that has the WolfSSL feature enabled.

Is this the direction you'd like to go with this?

(I've briefly checked whether WolfSSL crates are on crates.io already; my impression is that the wolfssl-sys could be fine, while the wolfssl crate is probably not -- but that's from a short glance and many heuristics AKA gut feeling).

[chrysn]

Suggested change

	#ifdef MODULE_WOLFSSL
	#if defined(MODULE_WOLFSSL) && !defined(IS_C2RUST)

While RIOT is "sloppy" about API and ABI, WolfSSL being a regular library should have all its interfaces bindgen-safe. If we start exposing external library's symbols (which I think we'll need to, because a regular -sys crate won't know the build flags and include paths the way we know them), making them bindgen-only should become best practice where possible.

[Flole998]

That wolfssl-sys crate does not support cross compiling at all. It will always attempt to compile for the host architecture, causing all kinds of issues.

Just so I understand it correctly: So you don't want whatever wolfSSL wrapper I might come up with in rust-riot-wrappers but suggest it should be an independent crate? That crate should then make use of either this PR or the wolfssl-sys one (if there is no cross-compiling involved)?

[chrysn]

Yes, that'd be the idea; riot-wrappers would then pull in the crate-to-be if there is, for example, a way to set up a DTLS socket with DTLS options that excede what's in credman. Looking at the headers you're including, this might already be the case soon: Anything from sock_tls.h would still go into riot-wrappers, but anything from wolfssl/ could be in its own crate. Procedurally, if it makes things easier, we can also start this off in a module of riot-wrappers, and split it off in the course of advancing the -wrappers PR. But let's not wait too long with using -sys as well, for that will guarantee we're staying honest to wrapping a library and not just some OS's view of that library. This all doesn't mean that all of WolfSSL will need to be wrapped, the API surface can still be the one that you need, but it'll be in a place where all users of WolfSSL through Rust can come together, rather than staying in a niche where it's hard to find people for sustainable maintenance.

[chrysn]

By the way, the changes for here look good; merging now only depends on CI's OK, and your resolve to stick with this even though it got more complex than you hoped ;-) (although I maintain that it won't be much more effort to maintain this the way I suggest than by just lugging it in with -wrappers).

[Flole998]

We have already started with the development in rust-riot-wrappers and it was really helpful to have such a base already. Unfortunately when we put it in a separate crate it won't really be maintained in the future by anyone, that's what I am a little worried about. So if someone wants to add new features the only way will be to fork it and then continue the work on it, which (from my experience) usually means that there will be several forks which all address individual problems.

Of course simply putting the burden of maintaining something on another person (in this case you) isn't an acceptable solution either. So simply starting a new crate and then abandoning it might be the best choice we have at this point, the other option would be not publishing it at all, which is probably even worse.

[chrysn]

If support for WolfSSL is just added here for sake of having the code in there, and there are no actual use cases, things will rot (and eventually be removed unless active users are around to keep things up to date) either way.

As for starting a crate and abandoning it, there are options that make it easier:

• On the crates.io side, there is the rust bus you can add as a maintainer. When all other maintainers are hit by a bus (metaphorically or literally), they'll hand control of the crate over to someone who's willing to do it and seems half-way capable.
• Communicate ahead of time. If the README says that this addresses an isolated use case and would need more active maintainers to add features, it won't come as a surprise to users who file a PR when you ask the submitter to become a co-maintainer.
• Gather users. As much as it pains the nerd in me to admit it, software development is at least as much a social challenge than it is a technical challenge. If there's any cool project that actually uses the code, chances are it'll take off more easily.

Note that due to whatever you're doing with sock_tls.h, there will already be one downstream: riot-wrappers. (Which will also mean that I'd probably join the crate team if invited).