Improving wolfSSL integration with the Espressif ESP-IDF (IDFGH-13019) #13966
Comments
github-actions
bot
changed the title
Just wanted to mention that it's unlikely that we would accept such a PR due to the fact that wolfSSL is not compatible with IDF's Apache 2.0 license. So we have to distribute wolfSSL via the component registry, instead. Outside of the scope of this ESP-IDF feature request, you might also want to include support for wolfSSL in https://github.com/project-chip/connectedhomeip, as that would allow using wolfSSL in Matter devices. |
|
Hi @igrr
I'm certainly not a licensing expert - but having only the This method does not seem to be much different that using a submodule as in esp-wolfssl, while offering the end user the ability to easily plug in a more recent version of wolfSSL simply by changing a setting in There would be no wolfSSL source code in the ESP-IDF components directory. I'm thinking the Kconfig options would allow something like this:
I'm open to suggestions, such as:
Is it possible to add core ESP-IDF support for wolfSSL via a Managed Component? For instance, if I have a project: The ESP-IDF environment does not see the local project managed component when compiling the IDF components. For example, I added this ... and of course the compiler does not see the local project component: I suppose the instructions could include copying that local project component to the ESP-IDF, but that seems a bit awkward. My goal is to make it as easy as possible for anyone to use wolfSSL instead of mbedTLS in their projects. Any other options or suggestions are appreciated. Thank you for taking a look at this issue. |
This (user having to specify paths in their system) is a pattern we are trying to avoid in ESP-IDF, because it results in projects which are not easily portable between different computers. Imagine a team of developers working on a project, and different developers have projects checked out in different locations. Options such as this one would be impossible to commit to a common sdkconfig file in the project repository. I think the component registry already provides a convenient way to install wolfSSL. The trend we want to see is that in the future, more features are moved out of ESP-IDF into standalone components. I'd like to avoid taking a step in the reverse direction.
This is possible, please see for example how it is done in esp-tls component. We possibly have to change that line a bit to also consider |
Yes, I agree. That's a very valid point. I've also considered an option where the
Great! That looks like a promising alternative. I don't see any It might be nice to have the user be able to select from the Yes: although I completely agree with your portability concerns, I still find the ability to point to a specific component version source code location to be a useful feature (e.g. pointing to a different GitHub repo directory, allowing changes to be easily checked in, or selected from different branches or releases). I could limit this to wolfSSL examples if you'd prefer not to have this feature in the ESP-IDF. Thanks very much being receptive to including wolfSSL in the ESP-IDF. |
The user would add idf_component.yml at the application level (e.g. in Other components (such as esp-tls and esp_wifi) can then detect the presence of wolfSSL component and enable the corresponding implementations — as done now in esp-tls, except for updating the component name.
This is still doable within the framework of the component manager. It allows specifying a dependency not only on a version published in the component registry, but also a branch or commit in a Git repository, or from a local directory: https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/manifest_file.html#dependencies-from-local-directory (and the section below). So I still don't see a strong need to introduce a Kconfig option for source code path, or handling of this option in CMake. |
AHA! I didn't understand the part about using I've confirmed by adding this line: idf_component_get_property(wolfssl wolfssl__wolfssl COMPONENT_LIB)... to the esp-tls/CMakeLists.txt like this: ... that indeed the ESP-IDF components can find the local project wolfssl Managed Component. That's a clever implementation! I like it!! I agree this is a considerably better way of implementing a 3rd party component in the ESP-IDF. Reminder for future reference: The In my There's a bit more work required on my part. In particular the currently published managed component (the 5.7.0 release) unfortunately does not include the Kconfig file setting for
For the typical end user, you are probably right. But from a component developer's perspective of modification of the component and contributing to the upstream source repository... how would you see that working? The Managed Component is static, disconnected source code, no? This is probably not an important issue for the ESP-IDF, but I personally find it quite appealing while developing the component. In the case of wolfSSL, there are continual, daily changes. @igrr - Thank you so much for your help. I'm glad I asked in advance! Stay tuned while I put together a PR and publish a fresh wolfssl managed component. Best Regards, Jim |
There is an additional property called Here is an example: https://github.com/espressif/idf-extra-components/blob/46213e9adb3fd3e09829afdbcb287cd2e5e06ea7/catch2/examples/catch2-console/main/idf_component.yml#L4. This line tells the component manager that if it is able to find a This approach works in cases when examples are somewhere inside a repository with the managed component, like with this When the component is uploaded to the registry, the registry automatically removes (I have tried to explain this and other things in my last year's talk (https://igrr.github.io/edc23/1, https://www.youtube.com/watch?v=D86gQ4knUnc), perhaps you could go through it again? I think it will answer some of your questions.) |
Ah, I see. That's a good idea. I'd certainly rather follow the standards.
@igrr I had forgotten about the presentation! Thank you for the reminder. It is very helpful. btw - It is an awesome presentation, particularly the companion https://igrr.github.io/edc23/1. Thanks again for all your help & feedback. |
Answers checklist.
General issue report
Improving wolfSSL integration with the Espressif ESP-IDF
This is an anchor GitHub issue to track the various upcoming pull requests and other issues related to improving the wolfSSL cryptographic library integration with the Espressif ESP-IDF.
The wolfSSL libraries are available for a given project, but the integration with the ESP-IDF core is not as robust as it should be.
There's a companion issue at wolfSSL: wolfSSL/wolfssl#7640
Features To Do
Reasons for choosing wolfSSL instead of mbedTLS
For serious commercial applications needing or users simply needing more capable, flexible, and actively supported libraries developers should choose wolfSSL.
wolfSSL is a TLS library. wolfSSL offers:
wolfSSL is the best tested crypto support, the #1 TLS in IoT and the first embedded TLS 1.3 platform with TPM 2.0, MQTT, FIPS 140 certification, hardware crypto acceleration and secure enclave support. All products are backed by 24/7 support.
Win32/64, Linux, OS X, Solaris, ThreadX, VxWorks, FreeBSD, NetBSD, OpenBSD, embedded Linux, Haiku, OpenWRT, iPhone (iOS), Android, Nintendo Wii and Gamecube through DevKitPro, QNX, MontaVista, OpenCL, NonStop, TRON/ITRON/µITRON, Micrium's µC OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, HP/UX, Keil RTX, TI-RTOS, Integrity OS"
- ARMv8 Cryptography Extensions
- RISC-V Assembly
- STM32 F2/F4/F7/L4/L5/U5/H5/H7 Hardware Crypto
- ATECC608B, ST-SAFEA110, SE050, IoT-Safe
- Single Precision Math (C and Assembly)
(complete manual, API reference, build instructions, extensions reference, tutorials, source code, benchmarking, examples)
Getting Started with wolfSSL
If you are new to wolfSSL on the Espressif ESP32, this video
can help to get started:
Additional ESP-IDF specifics can be found in Espressif/ESP-IDF. The wolfSSL Manual is also a useful
resource.
The core Espressif IDE information for wolfSSL can be found here:
https://github.com/wolfSSL/wolfssl/tree/master/IDE/Espressif
Included are the following examples:
Managed Components
The wolfSSL libraries are already available as Espressif Managed Components from the ESP Registry for installation to a specific project.
wolfSSLwolfssl/wolfsslwolfSSHwolfssl/wolfsshwolfMQTTwolfssl/wolfmqttwolfTPMwolfssl/wolftpm` (coming soon, see Initial Infineon I2C TPM support for Espressif ESP32 wolfSSL/wolfTPM#351)staging/test Managed Components at the Espressif Component Registry.
wolfSSLgojimmypi/mywolfsslwolfSSHgojimmypi/mywolfsshwolfMQTTgojimmypi/mywolfmqttwolfTPMwolfssl/wolftpm (coming soon, see Initial Infineon I2C TPM support for Espressif ESP32 wolfSSL/wolfTPM#351)For details on wolfSSL Managed Components, see these blogs:
PlatformIO
We are providing two different Official wolfSSL libraries for the ESP32: standard and another specifically for Arduino:
wolfssl/wolfSSL
wolfssl/Arduino-wolfSSL
There are also two different versions: the stable release versions (above) and these staging updates, with the latest post-release changes.
wolfssl-staging/wolfSSL
wolfssl-staging/Arduino-wolfSSL
See also the wolfSSL now supported on PlatformIO blog.
https://github.com/wolfSSL/wolfssl/tree/master/IDE/PlatformIO
Arduino
See Getting Started with wolfSSL on Arduino blog.
https://www.arduino.cc/reference/en/libraries/wolfssl/
https://github.com/wolfSSL/wolfssl/tree/master/IDE/ARDUINO
wolfSSL for the Apple HomeKit on the ESP32
See the https://github.com/AchimPieters/esp32-homekit-demo
AchimPieters/esp32-homekit-demo#3
Additional wolfSSL updates related to the Espressif environment
See ESP32 Espressif Improvements - Roadmap Summary #6234
Have an idea for other improvements? Feel free to open a new issue or send us an email [email protected]
The text was updated successfully, but these errors were encountered: