acassis commented on PR #20686: URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384420215
> Thanks for sharing your concerns. I understand your point about the security surface and the risk of importing code from another project. > > However, I think we also need to look at the current state of the native NuttX Bluetooth stack realistically. Today it is still at a very early stage and does not yet provide a complete BLE host stack. As far as I know, there is currently no real product or project using the native NuttX Bluetooth stack as a complete BLE solution. That makes it very difficult to use it directly for product work today. > > For commercial products, rewriting and validating a full Bluetooth host stack from scratch is usually not a realistic option. The protocol surface is large, the qualification and interoperability cost is high, and it takes a long time to reach a production-ready level. In practice, companies usually either buy a commercial stack or base their work on an existing mature open-source stack. > > This is also one of the reasons why ZBlue is useful here. Before moving to an open-source solution, some vendors had to rely on expensive commercial Bluetooth stacks. Now that openvela/NuttX needs an open stack that can continue to evolve in the open, starting from ZBlue gives us a practical path forward instead of starting from zero. > > I agree that security is a very important concern. But I think the CVE list can also be viewed from another angle: Zephyr Bluetooth is widely used, heavily tested, and actively analyzed by security researchers. Vulnerabilities are found because the stack is used and reviewed in many real products. If we maintain the NuttX port actively and keep tracking upstream fixes, we can benefit from that ecosystem instead of carrying an untested private implementation. > > If the concern is that users may misunderstand the maturity or security status, I am fine with making that clearer in the Kconfig/help text and documentation. For example, we can explicitly state that ZBlue is an optional Bluetooth host stack derived from Zephyr, that users should track security updates, and that it is not meant to imply that the native NuttX Bluetooth stack is being removed. > > I also agree with your suggestion that the Kconfig structure should make the choice explicit. Having something like this makes sense to me: > > ``` > Bluetooth Support > [ ] NuttX native BLE stack (WIP) > [ ] ZBlue (Zephyr Bluetooth stack) > [ ] NimBLE stack > ``` > > My only concern is that we should not block ZBlue just because the native stack is not yet complete. I see these as complementary options: > > * Native NuttX stack: long-term direction, but currently WIP > > * ZBlue: practical full-featured stack that can be maintained and improved now > > * NimBLE: another possible option if someone wants to integrate and maintain it > > > If this stack can be merged, my team is willing to help maintain it in NuttX. That includes tracking upstream security fixes, fixing integration issues, improving performance/resource usage, and handling compatibility problems. So I do not think this has to become an unmaintained foreign code dump. > > I agree that we should hear more opinions from other developers and maintainers. My main point is that adding ZBlue as an explicit optional stack gives NuttX users a practical Bluetooth solution today, while still leaving room for the native stack to continue improving. @anchao I agree 100% with everything you said, my only concern is assuming CONFIG_BT is ZBLUE you are removing the chance to let the NuttX native Bluetooth stack to become the default CONFIG_BT in the future. This is why I suggested using CONFIG_ZBLUE, just like we have CONFIG_NINBLE. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
