[jira] [Created] (HBASE-27813) REST Info Server improvements
Nihal Jain created HBASE-27813: -- Summary: REST Info Server improvements Key: HBASE-27813 URL: https://issues.apache.org/jira/browse/HBASE-27813 Project: HBase Issue Type: Umbrella Reporter: Nihal Jain Assignee: Nihal Jain -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27814) Add support for dump servlet in REST InfoServer
Nihal Jain created HBASE-27814: -- Summary: Add support for dump servlet in REST InfoServer Key: HBASE-27814 URL: https://issues.apache.org/jira/browse/HBASE-27814 Project: HBase Issue Type: Sub-task Reporter: Nihal Jain Assignee: Nihal Jain -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27816) Support option to auto bind to an available port for REST Info Server
Nihal Jain created HBASE-27816: -- Summary: Support option to auto bind to an available port for REST Info Server Key: HBASE-27816 URL: https://issues.apache.org/jira/browse/HBASE-27816 Project: HBase Issue Type: Sub-task Reporter: Nihal Jain Assignee: Nihal Jain -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27815) Add support for process metrics servlet in REST InfoServer
Nihal Jain created HBASE-27815: -- Summary: Add support for process metrics servlet in REST InfoServer Key: HBASE-27815 URL: https://issues.apache.org/jira/browse/HBASE-27815 Project: HBase Issue Type: Sub-task Reporter: Nihal Jain Assignee: Nihal Jain -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (HBASE-27817) Migrate javax.el:3.0.1-b08 to jakarta.el-4.0.2
Wes Schuitema created HBASE-27817: - Summary: Migrate javax.el:3.0.1-b08 to jakarta.el-4.0.2 Key: HBASE-27817 URL: https://issues.apache.org/jira/browse/HBASE-27817 Project: HBase Issue Type: Task Affects Versions: 3.0.0-alpha-4, 2.5.5, 2.4.18 Reporter: Wes Schuitema The javax.el artifact contains a CVE: [CVE-2021-28170. |https://nvd.nist.gov/vuln/detail/CVE-2021-28170]The CVE itself is not a big issue since we're pre-compiling our JSP pages when building HBase, no user input is parsed which reduces the risk considerably. The org.glassfish:javax.el artifact was moved to org.glassfish:jakarta.el, which means a migration to get rid of the CVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Scanning HBase for CVEs
I'm having a bit of trouble creating actionable issues. Some of the CVEs are low impact and/or found in largely unused transitive dependencies. Actually getting rid of the CVEs may not be worth the effort since the CVEs are not applicable, or some mitigating measures are already in place. We could add the issues anyway, so searching though Jira will give users/developers the context they need to determine if the CVE is acceptable. Regards, Wes On Wed, Apr 19, 2023 at 4:14 PM Wes Schuitema wrote: > Thanks, my pleasure. I'll translate our findings to some actionable Jira > issues later this week. > > Regards, > > Wes > > > > On Mon, Apr 17, 2023 at 1:06 PM Nick Dimiduk wrote: > >> Hi Wes, >> >> Thanks a lot for doing this work. Let's start burning down your list! >> >> On Tue, Apr 11, 2023 at 11:37 AM Wes Schuitema wrote: >> >> > We've scanned the HBase repositories (both hbase and hbase-thirdparty) >> for >> > CVEs using a Maven dependency-check plugin ( >> > https://jeremylong.github.io/DependencyCheck/dependency-check-maven/). >> >> >> There's also hbase-connectors, which will need to be monitored. Can we >> install this plugin into our builds? Raise a JIRA? >> >> The scan was done on the master branch (3.0.0-alpha-4) >> >> >> Master branch is a great place to start. We seem to maintain two active >> minor release lines, so we'll eventually want to also monitor those as >> well. >> >> The results of the check are included in the results section, >> > summarizing: >> > - We did not find any critical issues relevant to HBase >> > - Most of the CVEs can be safely suppressed so they will not show up >> again >> > in future scans >> > - Some CVEs can be easily fixed by updating a few minor dependencies >> > - Newer Hadoop versions also contain a lot of updates that remove CVEs >> > >> >> Fantastic! >> >> Steps we can take from here: >> > - Fix some minor issues on the master branch (update javax.el-3.0.1-b08 >> and >> > woodstox-core-5.3.0) >> > - Add dependency check to Maven configuration and suppress remaining >> CVEs >> > in a restrictive manner (e.g., scoped on CPE, with time limit, adding >> > helpful notes) >> > - Include CVE checking in the build process >> > >> >> This plan sounds good to me. >> >> Results >> > >> >> For each of these, you can start by filing a ticket with a subject like >> "Mitigate CVE-ABC", and set the "affectsVersions" field to the current >> release from each branch. For the description, put exactly what you have >> here, including your suggested resolution. Then the community can easily >> start implementing your suggestions. >> >> --- >> > Dependency: guava-31.1-jre.jar (from hbase-thirdparty) >> > CVEs: CVE-2020-8908 >> > Description: Deprecated method to create temporary files can makes those >> > files world readable, never used in the code base. >> > Action: Could suppress this CVE in combination with a checkstyle rule to >> > prevent usage of method >> > >> > Dependency: commons-beanutils-1.9.2.jar >> > CVEs: CVE-2014-0114, CVE-2019-10086 >> > Description: Brought in through commons-validator. CVEs can lead to >> remote >> > code in specific situations. This was never relevant in the HBase code >> base >> > since the code from the dependency is never used directly or indirectly. >> > The only code that is used from commons-validator is to validate ipv6 >> > addresses. >> > Action: Since the dependency was easy to update, we've done just that on >> > the master branch >> > >> > Dependency: commons-net-3.6.jar >> > CVEs: CVE-2021-37533 >> > Description: Brought in by hadoop-common. Library contains an FTP client >> > with a vulnerability. This client is never used in the HBase code base. >> The >> > latest Hadoop version (3.3.4) uses a version of this library without the >> > CVE. >> > Action: An update would remove this CVE, alternatively, we could prevent >> > usage of the FTPClient using checkstyle or something similar. >> > >> > Dependency: guava-27.0-jre.jar >> > CVEs: CVE-2020-8908 >> > Description: Deprecated method to create temporary files can makes those >> > files world readable, never used in the code base. >> > Action: Importing any Guava code unless from the hbase-thirdparty is >> > already banned. This CVE could be supressed. >> > >> > Dependency: hadoop-hdfs-3.2.4-tests.jar >> > CVEs: CVE-2020-11022, CVE-2020-11023, CVE-2015-6584, CVE-2022-24785, >> > CVE-2022-31129 >> > Description: CVEs are found in Javascript libraries present in this JAR >> > (jquery-3.4.1.min.js, jquery.dataTables.min.js, moment.min.js). Assuming >> > this code is only used in test situation this should not be an issue. >> We've >> > checked how HBase loads its own static resources and have concluded that >> > these libraries can never be accidentally served up by HBase. >> > Action: We can suppress these CVEs specifically for this dependency so >> it >> > will show up when the JavaScript libraries are introduced through some >> > other means. >> > >> > Dependency: hadoop-yarn-com
Re: Scanning HBase for CVEs
Simply cataloguing the CVE in Jira is a good start. The community can make a decision as for how to handle each one, and that decision is recorded on Jira, that ever the action may be. On Wed, Apr 26, 2023 at 15:39 Wes Schuitema wrote: > I'm having a bit of trouble creating actionable issues. Some of the CVEs > are low impact and/or found in largely unused transitive dependencies. > Actually getting rid of the CVEs may not be worth the effort since the CVEs > are not applicable, or some mitigating measures are already in place. We > could add the issues anyway, so searching though Jira will give > users/developers the context they need to determine if the CVE is > acceptable. > > Regards, > > Wes > > On Wed, Apr 19, 2023 at 4:14 PM Wes Schuitema wrote: > > > Thanks, my pleasure. I'll translate our findings to some actionable Jira > > issues later this week. > > > > Regards, > > > > Wes > > > > > > > > On Mon, Apr 17, 2023 at 1:06 PM Nick Dimiduk > wrote: > > > >> Hi Wes, > >> > >> Thanks a lot for doing this work. Let's start burning down your list! > >> > >> On Tue, Apr 11, 2023 at 11:37 AM Wes Schuitema wrote: > >> > >> > We've scanned the HBase repositories (both hbase and hbase-thirdparty) > >> for > >> > CVEs using a Maven dependency-check plugin ( > >> > https://jeremylong.github.io/DependencyCheck/dependency-check-maven/ > ). > >> > >> > >> There's also hbase-connectors, which will need to be monitored. Can we > >> install this plugin into our builds? Raise a JIRA? > >> > >> The scan was done on the master branch (3.0.0-alpha-4) > >> > >> > >> Master branch is a great place to start. We seem to maintain two active > >> minor release lines, so we'll eventually want to also monitor those as > >> well. > >> > >> The results of the check are included in the results section, > >> > summarizing: > >> > - We did not find any critical issues relevant to HBase > >> > - Most of the CVEs can be safely suppressed so they will not show up > >> again > >> > in future scans > >> > - Some CVEs can be easily fixed by updating a few minor dependencies > >> > - Newer Hadoop versions also contain a lot of updates that remove CVEs > >> > > >> > >> Fantastic! > >> > >> Steps we can take from here: > >> > - Fix some minor issues on the master branch (update > javax.el-3.0.1-b08 > >> and > >> > woodstox-core-5.3.0) > >> > - Add dependency check to Maven configuration and suppress remaining > >> CVEs > >> > in a restrictive manner (e.g., scoped on CPE, with time limit, adding > >> > helpful notes) > >> > - Include CVE checking in the build process > >> > > >> > >> This plan sounds good to me. > >> > >> Results > >> > > >> > >> For each of these, you can start by filing a ticket with a subject like > >> "Mitigate CVE-ABC", and set the "affectsVersions" field to the current > >> release from each branch. For the description, put exactly what you have > >> here, including your suggested resolution. Then the community can easily > >> start implementing your suggestions. > >> > >> --- > >> > Dependency: guava-31.1-jre.jar (from hbase-thirdparty) > >> > CVEs: CVE-2020-8908 > >> > Description: Deprecated method to create temporary files can makes > those > >> > files world readable, never used in the code base. > >> > Action: Could suppress this CVE in combination with a checkstyle rule > to > >> > prevent usage of method > >> > > >> > Dependency: commons-beanutils-1.9.2.jar > >> > CVEs: CVE-2014-0114, CVE-2019-10086 > >> > Description: Brought in through commons-validator. CVEs can lead to > >> remote > >> > code in specific situations. This was never relevant in the HBase code > >> base > >> > since the code from the dependency is never used directly or > indirectly. > >> > The only code that is used from commons-validator is to validate ipv6 > >> > addresses. > >> > Action: Since the dependency was easy to update, we've done just that > on > >> > the master branch > >> > > >> > Dependency: commons-net-3.6.jar > >> > CVEs: CVE-2021-37533 > >> > Description: Brought in by hadoop-common. Library contains an FTP > client > >> > with a vulnerability. This client is never used in the HBase code > base. > >> The > >> > latest Hadoop version (3.3.4) uses a version of this library without > the > >> > CVE. > >> > Action: An update would remove this CVE, alternatively, we could > prevent > >> > usage of the FTPClient using checkstyle or something similar. > >> > > >> > Dependency: guava-27.0-jre.jar > >> > CVEs: CVE-2020-8908 > >> > Description: Deprecated method to create temporary files can makes > those > >> > files world readable, never used in the code base. > >> > Action: Importing any Guava code unless from the hbase-thirdparty is > >> > already banned. This CVE could be supressed. > >> > > >> > Dependency: hadoop-hdfs-3.2.4-tests.jar > >> > CVEs: CVE-2020-11022, CVE-2020-11023, CVE-2015-6584, CVE-2022-24785, > >> > CVE-2022-31129 > >> > Description: CVEs are found in Javascript libraries present in this > JAR > >> > (jquery
Re: [DISCUSS] Do not send jira notification emails to dev list?
Gmail manages it pretty well for me, as a data point. Iteresting mails are promoted to the inbox. Other mail clients have similar features. I haven't been around much over the past month or so, so my hbase folder has > 1000 messages in it. It is true that discussions in dev@ are buried among the jira notifications. I have no idea what's been going on around here recently. So the board member's point is well taken. On the other hand the stream of jira notifications helps me see at a glance what has recently transpired, and is ordered in time. I am sure jira has some search feature which could do the same, but much more slowly, and subject to its spotty availability. Normally I like it, and it's more manageable when I am more active. On Fri, Apr 21, 2023 at 2:17 AM 张铎(Duo Zhang) wrote: > In the recent board report feedback, a board member suggested that we'd > better filter out the jira notification email from the dev list, otherwise > it is really hard to find out useful information. > > So what do you guys think about this? We already have an issues@hbase > mailing list to receive all the jira notifications and also github > notifications, for dev list we only send emails when an issue is created or > resolved. > > Thanks. > -- Best regards, Andrew Unrest, ignorance distilled, nihilistic imbeciles - It's what we’ve earned Welcome, apocalypse, what’s taken you so long? Bring us the fitting end that we’ve been counting on - A23, Welcome, Apocalypse
