Support upstream Mbed TLS #99
Conversation
|
Ping @jethrogb and @jack-fortanix. The essence of @gbryant-arm's change is the introduction of Mbed TLS as a submodule, and while there's still some cleanup to do here on our side, it would be good to know if you're in general supportive of this change. The rationale is that it will be easier to keep track of and update the version of Mbed TLS that the wrapper works with. We'd like this not only to ease support of upstream Mbed TLS, but also because we'd like to integrate the wrapper with an ongoing TLS 1.3 prototype implementation in Mbed TLS that we're working on. What are your thoughts? |
|
Sorry for the late response. I haven't looked at the changes in this PR yet, but we actually did think about the desired architecture here a couple of months ago with some folks from Red Hat. We think something more akin to the way the openssl-sys and openssl-src crates are organized is better. That way we can separate the bindings version from the MbedTLS version. A separate thing is the long-standing concern regarding bindgen. That's blocked on me spending some time evaluating the various open PRs for that. |
|
Close PR since long time no update |
This rejects spaces after field names as well as various other invalid characters. Fixes fortanix#96
AFAIK, in the current state of this project, the Mbed TLS "vendor" (hardcoded) version is tightly coupled to the wrapper and difficult to upgrade to a more recent version
since Mbed TLS is now built around a self-contained crypto module.Mbed Crypto is actually back into Mbed TLS (ARMmbed/mbed-crypto#374).
This work aims at supporting upstream Mbed TLS and potentially decoupling it from the wrapper.
What has been done so far:
This branch is based on jseyfried's branch fixing the issue with bindgen (and clang?) (#88).