Hi, This approach sounds good to me. I think it is better than a local TServlet fork.
Best, Dávid Andrew Purtell <[email protected]> ezt írta (időpont: 2026. máj. 29., P, 19:37): > I’m able to do the work to patch and onboard libthrift to thirdparty if we > agree this is an acceptable solution. > > > On May 28, 2026, at 2:12 PM, Andrew Purtell <[email protected]> > wrote: > > > > We could fork libthrift and retool the latest source release back to > javax and Java 8. Similar to how we maintain patches for protobuf and apply > them to fetched source distributions during the builds of hbase-thirdparty, > we would do the same for libthrift and then rebase the thrift gateway on a > new third party thrift module. While perhaps a fair amount of work it would > not break Java 8 compatibility. > > > > Alternatively we could survey users and decide to move on from Java 8 if > nobody speaks up otherwise. > > > >> On May 28, 2026, at 8:49 AM, Duo Zhang <[email protected]> wrote: > >> > >> There is a CVE in libthrift > >> > >> https://nvd.nist.gov/vuln/detail/CVE-2026-43869 > >> > >> which is fixed in 0.23.0. > >> > >> While trying to upgrade it in HBASE-30182, I found that libthrift has > >> already moved up to jakarta servlet api, instead of javax servlet api, > >> which makes it impossible to support java 8. > >> > >> We can move up to jakarta servlet api on master and branch-3 since we > >> only need to support java 17 there, and we already have a shaded jetty > >> 11 in hbase-thirdparty I believe? > >> But how to deal with branch-2.x? > >> Any suggestions? > >> > >> Thanks. >
