You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2026/06/01 23:06:00 UTC

[jira] (HBASE-30194) [thirdparty] Onboard libthrift to hbase-thirdparty

    [ https://issues.apache.org/jira/browse/HBASE-30194 ]


    Andrew Kyle Purtell deleted comment on HBASE-30194:
    ---------------------------------------------

was (Author: apurtell):
I have a PR for hbase-thirdparty [[here|https://github.com/apache/hbase-thirdparty/pull/160]] and a PR for this issue targeting master branch . 

> [thirdparty] Onboard libthrift to hbase-thirdparty
> --------------------------------------------------
>
>                 Key: HBASE-30194
>                 URL: https://issues.apache.org/jira/browse/HBASE-30194
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Kyle Purtell
>            Assignee: Andrew Kyle Purtell
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: thirdparty-4.1.14
>
>
> 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, Duo found that libthrift has moved up to jakarta 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. However we need a story for branch-2/2.5/2.6.
> The approach I would like to take is forking libthrift 0.23.0 (or latest) and retooling its 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 thirdparty build, we would do exactly 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. It handles thrift just like protobuf, which is a clean symmetry.
> This is required for branch-2/2.5/2.6.
> I'd also like to take this approach with branch-3 and up, so we don't face changes to the thrift gateway only in branch-2/2.5/2.6 (needed to retarget the codes to the thirdparty version of thrift), making backports more challenging, but that is not necessary for compatibility. I could go either way, please let me know your preference.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)