Hi Shawn,

Thanks for the great answers.  Thanks also to  Jörn Franke  and  Gus Heck
for responses.  The images were sent for convenience of the issues listed
below them.  We are working to get infosec approval.

It would be helpful to put the security links prominently on the solr
splash and download pages.

I also found these links to be useful:

        This is the Solr Security Wiki page with a list of CVE’s which
Sonatype reports.


https://wiki.apache.org/solr/SolrSecurity#Solr_and_Vulnerability_Scanning_Tools

Apache <https://www.cvedetails.com/vendor/45/Apache.html> » Solr
<https://www.cvedetails.com/product/18263/Apache-Solr.html?vendor_id=45> :
Security Vulnerabilities

https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-18263/Apache-Solr.html


---------- Forwarded message ---------
From: Shawn Heisey <apa...@elyograg.org>
Date: Fri, Jan 4, 2019 at 1:49 PM
Subject: Re: SOLR v7 Security Issues Caused Denial of Use - Sonatype
Application Composition Report
To: <solr-user@lucene.apache.org>


On 1/3/2019 11:15 AM, Bob Hathaway wrote:
> We want to use SOLR v7 but Sonatype scans past v6.5 show dozens of
> critical and severe security issues and dozens of licensing issues.

None of the images that you attached to your message are visible to us.
Attachments are regularly stripped by Apache mailing lists and cannot be
relied on.

Some of the security issues you've mentioned could be problems.  But if
you follow recommendations and make sure that Solr is not directly
accessible to unauthorized parties, it will not be possible for those
parties to exploit security issues without first finding and exploiting
a vulnerability on an authorized system.

Vulnerabilities in SolrJ, if any exist, are slightly different, but
unless unauthorized parties have the ability to *directly* send input to
SolrJ code without intermediate code sanitizing the input, they will not
be able to exploit those vulnerabilities. JSON support in SolrJ is
provided by noggit, not jackson, and JSON/XML are not used by recent
versions of SolrJ unless they are very specifically requested by the
programmer.  Are there any vulnerabilities you've found that affect
SolrJ itself, separately from the rest of Solr?

As we become aware of issues with either project code or third-party
software, we get them fixed.  Sometimes it is not completely
straightforward to upgrade to newer versions of third-party software,
but staying current is a priority.

Licensing issues are of major concern to the entire Apache Foundation.
As a project, we are unaware of any licensing problems at this time.
All of the third-party software that is included with Solr should be
available under a license that is compatible with the Apache license.  I
didn't examine the list you sent super closely, but what I did look at
didn't look like a problem.

https://www.apache.org/legal/resolved.html#category-b

The mere presence of GPL in the available licenses for third party
software is not an indication of a problem.  If that were the ONLY
license available, then it would be a problem.

Thanks,
Shawn

Reply via email to