anchao commented on PR #20686:
URL: https://github.com/apache/nuttx/pull/20686#issuecomment-6384335944
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.
--
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]
