We have replied to this person’s “monthly reminders” multiple times but they are apparently not subscribed to the list, so they do not see them. It’s almost becoming a troll at this point, to repeatedly attempt to shame a community for not answering but not bothering to join the community to know if they are answering.
The simple answer is the vast majority of the items on the list are on the wiki page that tracks 3rd party dependencies that are *not* real vulnerabilities in Solr: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity. Any questions not addressed by that page should be handled in accordance with the community security policy: https://solr.apache.org/security.html. On Sep 1, 2021, 10:53 AM -0500, Dave <hastings.recurs...@gmail.com>, wrote: > Agreed. Solr should always have a front end to interface with the server > itself. I don’t think I’ve ever seen a situation where it was accessible > outside of the internal network. Not to mention it gives you an extra layer > to add parameters or clean user input. Raw solr is for the developers, that > make the interface to the user input > > > On Sep 1, 2021, at 11:28 AM, Shawn Heisey <elyog...@elyograg.org> wrote: > > > > On 9/1/2021 8:25 AM, Narayanan, Lakshmi wrote: > > > This is my monthly reminder to SOLR support groups > > > Please advise if the below listed vulnerabilities have been resolved in > > > higher versions of SOLR > > > Any response to this message will be gratefully received > > > > The vast majority of any vulnerabilities will be impossible to exploit if > > you follow one of the most basic security steps: Make sure that Solr is not > > accessible to the outside world. At the network and/or OS level, make sure > > that only the IP addresses of people and applications that need Solr are > > able to access whatever port Solr is listening on. > > > > > /opt/solr-8.8.2/example/example-DIH/solr/db/lib/derby-10.9.1.0.jar > > > > Whatever the vulnerability is here, it can only be a problem if you > > actually use the derby database with the dataimport handler. > > > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/hadoop-annotations-3.2.0.jar > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/hadoop-auth-3.2.0.jar > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/hadoop-common-3.2.0.jar > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/hadoop-hdfs-client-3.2.0.jar > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/htrace-core4-4.1.0-incubating.jar:jackson-databind > > > /opt/solr-8.8.2/server/solr-webapp/webapp/WEB-INF/lib/htrace-core4-4.1.0-incubating.jar:jackson-databind > > > > Are you using the HDFS filesystem support in Solr? If you're not, then > > these jars are not used and you won't need to worry about it. > > > > I'll say the first thing I said again: The vast majority of any > > vulnerabilities will be impossible to exploit if you follow one of the most > > basic security steps: Make sure that Solr is not accessible to the outside > > world. At the network and/or OS level, make sure that only the IP addresses > > of people and applications that need Solr are able to access whatever port > > Solr is listening on. > > > > If you can't trust your own people, that is an internal security issue for > > your organization, and the Solr project cannot help with it. > > > > Thanks, > > Shawn > >
