On 2024/05/29 00:24:08 ZhangJian He wrote: > Yesterday, I manually triggered CI for branch/4.16, but it failed. I think > the root reason is gRPC's version is not compatible with netty. And > branch/4.16's gRPC contains several CVEs. I think we need to discuss > whether to update the gRPC version in branch/4.16
Upgrading gRPC is usually a breaking change. There might also be a need to change the Protobuf version when upgrading gRPC. It's actually the Protobuf version change that causes the trouble. Protobuf protoc generated code often breaks when Protobuf version is upgraded. This will also impact Pulsar users since the gRPC and Protobuf versions have to match the Bookkeeper versions because of how Pulsar is packaged (All Pulsar and Bookkeeper dependencies are in the same classpath). The compatibility policy of protobuf (https://protobuf.dev/support/cross-version-runtime-guarantee/) states that cross-version runtime support isn't guaranteed. I have also understood that grpc has a similar policy. Since grpc usage involves generated code (generated with protoc gprc plugin), it seems that gprc upgrades have similar impacts as protobuf upgrades. However for Pulsar end users, the gRPC version doesn't get exposed via Pulsar client dependencies like it does for protobuf-java (reported issue https://github.com/apache/pulsar/issues/22263). I have shared some thoughts on possible ways to address this in a previous email thread, https://lists.apache.org/thread/odg7p617zwqjngq6fk6qf8xfzbfwgfgq . In branch-4.16 maintenance, we would have to prioritize avoiding breaking changes over resolving low or medium level CVEs. It's not feasible to get rid of all possible CVEs without causing breaking changes. We have to make tradeoffs. I'd rather have exemptions for low and medium level CVEs than causing breaking changes for our users that upgrade to a new version of a Pulsar LTS version. We use Bookkeeper branch-4.16 in Pulsar LTS (3.0.x). -Lari
