Hello Nick, Our current plan is to finish creating our overview of the currently detected CVEs. We will share this overview with private@, including a proposal on how to proceed; what to suppress, what to accept, creating issues, etc.
It's probably more convenient to start working on CVE detection in the build process after we have the overview. We at least want to suppress any accepted CVEs or false positives. Also, maybe it's not worth the hassle to fail all builds if a new CVE is encountered (which may be minor or a false positive). Maybe a process parallel to the nightly builds is an option. We don't know much about Yetus yet, but we could add it there. If we only check when dependencies change, we run the risk of missing new CVEs found in existing dependencies. Regarding the protobuf-2.5 dependency, sounds like a good option from our perspective. Is there a target release date for HBase 3? On Wed, Mar 22, 2023 at 12:55 PM Nick Dimiduk <ndimi...@apache.org> wrote: > Hi Wes, > > Comments inline. > > On Wed, Mar 8, 2023 at 1:44 PM Wes Schuitema <w...@web-iq.com> wrote: > > > We could proceed as follows: > > - We keep on working finding out which CVE's are relevant, which we want > to > > do anyway. We do need to know if it's okay to discuss the results on the > > mailing list or Jira or if we can maybe do some pruning beforehand > together > > with someone more HBase knowledge. > > > > If you have any doubt about where to discuss a CVE, you can start by > emailing the private@ list to check. This is a non-public place where the > PMC can make a determination, with support from the ASF Security > organization. > > > > - Add the dependency-check-maven as a build plugin so we can perform the > > scan manually. Suppressing false positives and accepted CVE's. We always > do > > this in an XML configuration file which also serves as a sort of > > documentation for developers. > > > > This seems like an actionable task. Maintaining its configuration across > active release lines may prove painful. > > -Decide on how to incorporate the CVE checks in the development process > > (e.g., add to a build step or configure nightly checks) > > > > A check could be a matter of enabling the dependency-check plugin. We could > do this in the nightly builds and in PRs. We could extend the Yetus > personality used in PRs to only run the plugin when the dependencies are > changed. > > - Work on fixing remaining issues, tracked in Jira > > > > +1 > > And to speak again re: the protobuf-2.5 dependency -- there's nothing > stopping us producing a 3.0 release that is the current branch-2 with the > protobuf upgrade... master branch becomes 4.0-SNAPSHOT and we move forward. > > Thanks, > Nick > > On Tue, Mar 7, 2023 at 2:40 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > > > Thanks for looking at security problems. > > > > > > All ASF projects follow the same way to process security problems, > please > > > see here > > > > > > https://www.apache.org/security/ > > > > > > And on the CVEs from dependencies, usually the HBase community will fix > > it > > > ASAP. And we have also enabled dependabot on github to help us fixing > > > dependencies CVEs(only for master branch, although). > > > > > > The protobuf 2.5 dependency is a bit difficult, as Nick said, it will > > break > > > our compatibility guidelines if we just upgrade it or remove it, > > especially > > > that all the CPEPs for branch-2.x still depend on it, doing this will > > break > > > Phoenix and other projects which are based on HBase... > > > > > > Thanks. > > > > > > Nick Dimiduk <ndimi...@apache.org> 于2023年3月7日周二 20:08写道： > > > > > > > Hi Wes, > > > > > > > > Thanks a lot for your interest. I think that you'll find this > community > > > is > > > > interested in squashing CVEs. As you can see in the description > > > > on HBASE-27436, doing so in a way that meets our strict > > > > compatibility guidelines can be technically challenging. Flagging the > > > > attention of specific issues for the community via a nightly build > > > process, > > > > as per HBASE-20553, seems like a decent enough idea, especially if > > there > > > > are people actively interested in pursuing the results of the > scanner. > > My > > > > previous experience with OWASP specifically is that it cannot perform > > the > > > > analysis to decide if a CVE is actually exploitable, and so without > > > > committed human collaboration, the tool (1) generates useless noise > and > > > (2) > > > > degrades the confidence of casual passers-by in the quality of the > > > product. > > > > > > > > All that said, I think that there are several of us around the > > community > > > > who would be interested in collaboration around addressing these > types > > of > > > > issues. I'd hate for you to be doing the effort AND be forced into > > > > maintaining a fork. Let's get your fixes merged. > > > > > > > > How would you propose that we proceed? Do you have patches you'd like > > to > > > > see landed upstream? We can start by getting you a JIRA account if > you > > > > don't already have one. Start by filing a request on the self-service > > > tool, > > > > https://selfserve.apache.org/jira-account.html > > > > > > > > Thanks, > > > > Nick > > > > > > > > On Tue, Mar 7, 2023 at 11:03 AM Wes Schuitema <w...@web-iq.com> > wrote: > > > > > > > > > Hello devs, > > > > > > > > > > When doing a security audit on the software we're using we've > found a > > > few > > > > > CVEs in HBase. We've been looking into the mailing list and Jira in > > > order > > > > > to see if these are known and/or accepted CVEs and have found some > > > > related > > > > > issues. > > > > > > > > > > One of the detected CVEs is mentioned in an issue as low priority > in > > > this > > > > > issues: https://issues.apache.org/jira/browse/HBASE-27436 (Remove > > > > protobuf > > > > > 2 dependencies). Which looking at the priority and description > seems > > to > > > > be > > > > > an accepted CVE. > > > > > > > > > > There are also two issues mentioning integrating CVE checking to > the > > > > build > > > > > process: > > > > > - https://issues.apache.org/jira/browse/HBASE-20553 (Add > dependency > > > CVE > > > > > checking to nightly tests) > > > > > - https://issues.apache.org/jira/browse/HBASE-20971 (Please add > > OWASP > > > > > Dependency Check to the core build (pom.xml) and all sub-component > > > > builds.) > > > > > Both have a high priority, but are also several years old. Is this > > > > > something that is still interesting for the project and worth > looking > > > > into? > > > > > > > > > > We were able to find some messages on the mailing list mentioning > > > > updating > > > > > dependencies because of CVEs in release notes. But we've not found > > any > > > > > documentation mentioning a process of detecting and addressing > CVEs. > > > > > > > > > > We want to work on addressing these CVEs in our own installation. > We > > > want > > > > > to find out which CVEs are relevant, and fix any relevant CVEs. It > > > would > > > > be > > > > > nice if we could get these changes merged somehow so we don't have > to > > > > > maintain our own HBase fork. Updating dependencies can also come > with > > > > some > > > > > subtle problems that may be difficult to solve without some advise > > from > > > > the > > > > > community, is this worthwhile enough to to invest time into? > > > > > > > > > > Regards, > > > > > > > > > > Wes > > > > > -- > > > > > > > > > > - Winner of Dutch Innovation award within Law Enforcement > > > > > - Active in 26 countries > > > > > > > > > > Wes Schuitema > > > > > Software Engineer > > > > > > > > > > phone: > > > > > skype: > > > > > site: > > > > > pgp: +31 (0)50 21 11 622 > > > > > w...@web-iq.com > > > > > web-iq.com > > > > > 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA > > > > > The content of this email is confidential and intended for the > > > recipient > > > > > specified in message only. It is strictly forbidden to share any > part > > > of > > > > > this message with any third party, without a written consent of the > > > > sender. > > > > > If you received this message by mistake, please reply to this > message > > > and > > > > > follow with its deletion, so that we can ensure such a mistake does > > not > > > > > occur in the future. > > > > > > > > > > > > > > > > > > -- > > > > - Winner of Dutch Innovation award within Law Enforcement > > - Active in 26 countries > > > > Wes Schuitema > > Software Engineer > > > > phone: > > skype: > > site: > > pgp: +31 (0)50 21 11 622 > > w...@web-iq.com > > web-iq.com > > 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA > > The content of this email is confidential and intended for the recipient > > specified in message only. It is strictly forbidden to share any part of > > this message with any third party, without a written consent of the > sender. > > If you received this message by mistake, please reply to this message and > > follow with its deletion, so that we can ensure such a mistake does not > > occur in the future. > > > -- - Winner of Dutch Innovation award within Law Enforcement - Active in 26 countries Wes Schuitema Software Engineer phone: skype: site: pgp: +31 (0)50 21 11 622 w...@web-iq.com web-iq.com 67ED A1AB 34EF CA75 1F88 F2E2 ADC0 E1DD 6905 D5EA The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.
