-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
install script for wolfssl component (IDFGH-7747) #9288
Conversation
Thanks for your contribution. |
@gojimmypi We have different approach for using We would recommend any possible improvements be sent over as PR to our fork at https://github.com/espressif/esp-wolfssl |
@mahavirj thanks for taking a look at this PR. I've had a difficult time with the I was hoping for something easier to use and a bit more tightly integrated into the ESP-IDF |
Thanks for notifying! We will prioritize updating our fork to latest woflssl release. In case you have any existing work, please feel free to raise PR.
We do not recommend any additional commands or installation scripts in our components. In-fact, in longer run we will be recommending our IDF component manager (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-component-manager.html) for using any third party libraries or frameworks, as it shall provide more seamless experience with our build system. We will evaluate if we can consider |
Cool! I was not aware of the new IDF Component Manager. Thanks for the heads up. That looks like quite a big change in the framework and will be a good improvement for developers. I took a look at the API Guide: Using with a Project, but was not able to find the example mentioned: As noted in espressif/idf-component-manager#4
If you have any other information on 3rd party components I will take a look. In the docs there's currently mention of:
What can I do to help get wolfSSL listed as a component? Given all this, I'd like to improve the wolfSSL installation process sooner than later. As this PR is only for a handful of git commands in a script, I'm wondering if it could kindly be merged until the new component architecture is fully implemented? In the meantime I will be working towards getting an installation ready for when the new Component Manager is available. I definitely see the value there. Any additional guidelines for implementation will be appreciated. Ideally, something as important as security and encryption needed in practically every application should be tightly integrated and easy to use within any development environment. This will probably be of highest interest to the large volume, commercial users of the Espressif product line. We are definitely in agreement with regards to our mutual objective:
Thanks again! Cheers. |
Hi @gojimmypi Thanks for your contribution. I have answered some of the questions in a similar thread here
Thanks, |
This should be addressed with espressif/esp-wolfssl@470c02f. I recommend that we followup on |
Hi @AdityaHPatwardhan thank you for the example component. I'm currently trying to get ESP-IDF v5 working in Visual Studio as noted in espressif/idf-installer#142. Once I get my dev environment working, your example will be very helpful. @mahavirj - that's awesome you updated the submodule for wolfSSL! Thank you. :) Regarding:
I've thought about this more and yes: I can see that would be a wise choice. I do however strongly believe there should be some mechanism to more easily install critical security components. Although the current esp-wolfssl has been updated, we've seen how easy it is for the submodule to quickly become stale. What do you think would be a good mechanism to ensure that every user that installs a fresh wolfSSL component is always assured of getting the latest release? Instead of an install script, how about just a There were quite a few changes in the latest wolfSSL release. Unlike other components such as peripherals and communication libraries, something as fundamental as security should be "baked-in" at a much tighter and lower level, and certainly not treated as an add-on. My main objective is to ensure the security features are as easy and ubiquitous as any other standard library. I believe it is important for people like us to silver-platter security to end users so that the first thing they think of is using security features such as encryption and not bolting it on later as an afterthought. Although the new Espressif component manager may address this, I still think it would be beneficial all around if the version 4.x components included information on how to more tightly integrate wolfSSL components either in the ESP-IDF, and/or information on how to include directly in the project such as I did with my SSH to UART project. What do you think? In any case, @mahavirj thanks again very much for updating the esp-wolfssl and considering my ideas. :) I look forward to hearing your ideas. cheers |
We can easily align submodule update on our fork with wolfSSL release cycle. We are open for PRs on this repo or we can handle it internally as well. Regarding usage model, I would still prefer approach documented at https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_tls.html#how-to-use-wolfssl-with-esp-idf. This has an advantage as our TLS abstraction layer ( |
this PR adds a
wolfSSL_README.md
file along with an install script in a newcomponents/wolfssl
directory that allows users of the ESP-IDF to easily install the wolfSSL component.