Thanks for Lari's help. No pr in https://github.com/apache/bookkeeper/pulls?q=is%3Apr+label%3Arelease%2F4.16.6+is%3Amerged+-label%3Acherry-picked%2Fbranch-4.16 . And CI is passed https://github.com/apache/bookkeeper/actions/runs/9498228206. I'll start preparing for the RC as soon as I can.
Thanks ZhangJian He Twitter: shoothzj Wechat: shoothzj On Fri, Jun 7, 2024 at 4:18 PM ZhangJian He <shoot...@gmail.com> wrote: > +1 for downgrade to 4.1.100.Final > > Thanks > ZhangJian He > Twitter: shoothzj > Wechat: shoothzj > > > On Fri, Jun 7, 2024 at 4:18 PM zhiheng123 <903292...@qq.com.invalid> > wrote: > >> I found that this exception was caused by the upgrade of netty. If you >> revert netty to 4.1.100.Final, the use case passes. Because in >> 4.1.101.Final, netty modified the Http2 related interfaces, the connection >> is as follows: https://netty.io/news/2023/11/09/4-1-101-Final.html >> >> >> >> The main reason may be incompatibility caused by (#13651). I recommended >> to roll back netty to 4.1.100.Final, which can also address some CVE >> vulnerabilities related to netty. This will allow the ci of branch-4.1.16 >> to return to normal without having to upgrade the version of grpc. The >> corresponding components related to netty such as vertx also need to be >> rolled back to the version that matches netty. >> >> >> >> >> >> >> >> I have successfully passed the integration test in my personal branch >> >> >> >> https://github.com/zhiheng123/bookkeeper/actions/runs/9402997637 >> >> >> Original Email >> >> >> Sender:"Lari Hotari"< lhot...@apache.org >; >> >> Sent Time:2024/5/29 14:30 >> >> To:"dev"< dev@bookkeeper.apache.org >; >> >> Subject:Re: [DISCUSS] BookKeeper 4.16.6 release >> >> >> 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 > >
