Update codebase, improve component installation

[gojimmypi]

I opened espressif/esp-idf#9288 in the hopes of improving the wolfSSL component integration with the ESP-IDF.

In the comments of the PR I learned there's a completely new and exciting IDF Component Manager in the works, but not quite complete as noted in espressif/idf-component-manager#4 (comment):

Component Manager was released recently and at this stage, it's only available for uploading internal (Espressif) components.

In the meantime, the wolfSSL code here in this repo has grown quite stale. The current submodule points to code that is well over a year old.

I'd like to help. It sounds like updating this repo may or may not be the best place for a new wolfSSL component? Any suggestions of how best to proceed will be appreciated. Thanks.

See also: https://www.wolfssl.com/Espressif/ as well as current install scripts for wolfSSL and wolfSSH.

[AdityaHPatwardhan]

Hi @gojimmypi Thanks for the issue and your PR.

I have tried to best explain the current scenario as follows:

1. In esp-idf we are currently in process of moving all the components other than the core components to the IDF Component Manager. esp-wolfssl is not a core component, Hence I dont think it would be accepted in the esp-idf as of now.

2. Regarding your alternate approach of adding esp-wolfssl to IDF Component Manager. I think that is the preferable approach here, but it currently has a small issue:
   The policy of the component manager is that any component in esp-idf should not depend on a component in the IDF component manager. Currently esp-tls component directly depends on esp-wolfssl component.
   The problem for this being that the naming convention of a component in the component manager is not expected to be constant as of now. We are in a process of evaluating if esp-wolfssl component should be added to the IDF Component Manager. I think that shall only be done once this small issue is fixed.

[gojimmypi]

Hi @AdityaHPatwardhan and thank you for the explanation.

any component in esp-idf should not depend on a component in the IDF component manager.

I completely agree. That's why I propose that wolfSSL should be considered a core component as noted in my comment. I saw espressif/esp-idf#9288 was closed with the resolution Won't do.

There is a LOT more to wolfSSL than just the TLS capabilities used by the esp-tls: wolfcrypt FIPS, DTLS, TPM, MQTT, SSH, and more. These are important security and encryption capabilities that should be easily available to all users for modern and robust application implementations.

Other vendors do this. For instance: in the STM32 CubeMX IDE, wolfSSL is a baked-in component as basic as freeRTOS:

Once installed, wolfSSL is then easily available for all future projects, and easily updated to latest version:

Really my only goal here is to make security easy to use for the ESP32; security that is used from the very beginning of a project and not bolted on later as an afterthought. :) What do you think would be best?

Thanks again for taking a look at this.

[igrr]

@AdityaHPatwardhan could you please explain this part?

The problem for this being that the naming convention of a component in the component manager is not expected to be constant as of now.

I think we already expect this, e.g. for the dependency of esp_local_ctrl on espressif/mdns in https://github.com/espressif/esp-idf/blob/495d35949d50033ebcb89def98f107aa267388c0/components/esp_local_ctrl/CMakeLists.txt#L26.
So it's okay to do the same for wolfssl, i think:

idf_component_optional_requires(PRIVATE espressif__wolfssl esp-wolfssl)

The first captures dependency on espressif/wolfssl, the second is a fallback in case esp-wolfssl is added to EXTRA_COMPONENT_DIRS.

[AdityaHPatwardhan]

Hi @igrr Thank you for your suggestion. It seems I was under a false assumption that we cannot have the direct dependency of an esp-idf component on a component from the IDF-component-manager.
@gojimmypi I apologise for the delay from my side, I shall raise respective MR in esp-idf for making the changes and update here.

[igrr]

we cannot have the direct dependency of an esp-idf component on a component from the IDF-component-manager.

That's true in general, but sometimes we can make an exception and allow a weak (optional) dependency to inject some functionality into a core component from an external component. The core component should still be able to work if the optional dependency is not installed. Since that is the case here, and esp-tls already supported WolfSSL integration, I think this is an acceptable solution.

[gojimmypi]

@igrr thank you! What can I do to help make the wolfSSL component integration seamless and effective?

@AdityaHPatwardhan no worries at all. I think we all have the same objective: to have robust, reliable, Best Practice solutions. I respect your diligence and attention to detail.

There's definitely interest for not only the current component library and new component manager , but also the cross-architecture support for hardware encryption acceleration using the best of the Espressif HAL features for wolfSSL capabilities beyond the esp-tls library.

I'm happy to help in any way I can.

[gojimmypi]

Hello @igrr - are you able to help me move this esp-wolfssl repo over to wolfssl and setup a new component at components.espressif.com? Thank you.

[gojimmypi]

An exciting update on this issue! As noted in espressif/idf-component-manager#4 (comment) : @kumekay kindly help me setup wolfSSL as a component in the ESP Managed Components Registry!

I've created #22 to let everyone know.

I'll leave this issue open as there's still the topic of what to to with this esp-wolfssl repository. Perhaps it would make sense to move it to wolfSSL?