Re: Zookeeper and Solr and CVE-2021-44228
To unsubscribe, see https://solr.apache.org/community.html#mailing-lists-chat Jan > 15. des. 2021 kl. 04:30 skrev John Eberly : > > unsubscribe > > > On Mon, Dec 13, 2021 at 8:53 AM Walter Underwood > wrote: > >> Zookeeper 3.5.7 uses log4j 1.x, so is not vulnerable. I checked. >> >> wunder >> Walter Underwood >> wun...@wunderwood.org >> http://observer.wunderwood.org/ (my blog) >> >>> On Dec 13, 2021, at 6:20 AM, Michael Conrad wrote: >>> >>> I presume this also needs fixing for zookeeper nodes? >>> >>> On 12/10/21 13:44, Walter Underwood wrote: Does all Solr logging go through slf4j? If so, that should protect >> against this vulnerability. If not, who has tested Solr with log4j 2.15.1? We are running 8.8.2. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) >> >>
Read-only user in solr not working as expected
Dear solr community,
I would like to create two users in solr: An admin and a dev.
The dev should not be able to edit the solr metadata. This user should
not be able to use solr.add or solr delete, I would like him only to be
able to use solr.search for our metadata solr-core (in python pysolr).
However, the user can always use solr.add and solr.delete, no matter
what permissions I set for him. Here is my security.json:
{
"authentication":{
"blockUnknown":true,
"class":"solr.BasicAuthPlugin",
"credentials":{
"my_admin":"",
"my_dev":""},
"forwardCredentials":false,
"":{"v":0}},
"authorization":{
"class":"solr.RuleBasedAuthorizationPlugin",
"user-role":{
"my_admin":["admin"],
"my_dev":["dev"]},
"permissions":[
{
"name":"security-edit",
"role":["admin"],
"index":1},
{
"name":"read",
"role":["dev"],
"index":2}],
"":{"v":0}}
}
I also tried `zk-read`, `metics-read`, `security-read`,
`collection-admin-read` instead of `read`, always with the same result.
The user my_dev can always use solr.add and solr.delete.
Greetings
Martin
--
Martin Schober
Arbeitsgruppe: Faserbahnarchitektur (FA)
Institut für Neurowissenschaften und Medizin
Strukturelle und funktionelle Organisation des Gehirns (INM-1)
Telefon: +49 2461 61-9148
E-Mail: m.scho...@fz-juelich.de
Geb. 15.9, Raum 4017
Homepage:
http://www.fz-juelich.de/SharedDocs/Personen/INM/INM-1/DE/Schober_Martin.html
-
-
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Astrid Lambrecht,
Prof. Dr. Frauke Melchior
-
-
smime.p7s
Description: S/MIME Cryptographic Signature
Using join queries with synchronous filterCache is not supported
Hi List, Since upgrading from solr 8.8.2 to 8.11.0 we get the following error message: Using join queries with synchronous filterCache is not supported! Details can be found in Solr Reference Guide under 'query-settings-in-solrconfig'. Looking at the commit history this was recently added: https://github.com/apache/solr/commits/2d395989017cc28473dbe60d9a1e9e9301bf9112/solr/core/src/java/org/apache/solr/search/JoinQuery.java For now we needed to disable the filter cache completely on the main core/index to make searches work. We are concerned about loss of performance. Is there any documentation on how to correctly configure the filter cache on 8.11.0 ? Best Regards Jens Jens Viebig Software Developer o: +49 4307 8358 0 f: +49 4307 8358 699 jens.vie...@vitec.com www.vitec.com Legal Notice Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. Neither VITEC S.A. (66 Avenue des Champs Elysées – 75008 Paris - France) nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. VITEC GmbH, Lise-Meitner-Str. 15, 24223 Schwentinental Geschäftsführer/Managing Director: Philippe Wetzel HRB Plön 1584 / Steuernummer: 2029706365 / VATnumber: DE134878603
Re: Using join queries with synchronous filterCache is not supported
Hello, Jens. Have you considered turning async=true for the cache? On Wed, Dec 15, 2021 at 1:49 PM Jens Viebig wrote: > Hi List, > Since upgrading from solr 8.8.2 to 8.11.0 we get the following error > message: > > Using join queries with synchronous filterCache is not supported! Details > can be found in Solr Reference Guide under 'query-settings-in-solrconfig'. > > Looking at the commit history this was recently added: > > https://github.com/apache/solr/commits/2d395989017cc28473dbe60d9a1e9e9301bf9112/solr/core/src/java/org/apache/solr/search/JoinQuery.java > > For now we needed to disable the filter cache completely on the main > core/index to make searches work. We are concerned about loss of > performance. > > Is there any documentation on how to correctly configure the filter cache > on 8.11.0 ? > > Best Regards > Jens > > Jens Viebig > Software Developer > o: > +49 4307 8358 0 > f: > +49 4307 8358 699 > jens.vie...@vitec.com > www.vitec.com > > Legal Notice > Unless expressly stated otherwise, this message is confidential and may > be privileged. It is intended for the addressee(s) only. Access to this > e-mail by anyone else is unauthorized. If you are not an addressee, any > disclosure or copying of the contents of this e-mail or any action taken > (or not taken) in reliance on it is unauthorized and may be unlawful. If > you are not an addressee, please inform the sender immediately. Neither > VITEC S.A. (66 Avenue des Champs Elysées – 75008 Paris - France) nor any of > its subsidiaries or affiliates shall be liable for the message if altered, > changed or falsified. VITEC GmbH, Lise-Meitner-Str. 15, 24223 Schwentinental > Geschäftsführer/Managing Director: Philippe Wetzel > HRB Plön 1584 / Steuernummer: 2029706365 / VATnumber: DE134878603 > -- Sincerely yours Mikhail Khludnev
Log4J saga (CVE-2021-45046)
Hi all, Looks like we are not done with log4j security problems. Someone has recommendations about CVE-2021-45046? Eric Briere
Re: Log4J saga (CVE-2021-45046)
Isn't the example with "zip -q -d ..." as reported in the CVE not working for you? Regards Bernd Am 15.12.21 um 13:40 schrieb e_bri...@videotron.ca: Hi all, Looks like we are not done with log4j security problems. Someone has recommendations about CVE-2021-45046? Eric Briere
Re: Log4J saga (CVE-2021-45046)
We just upgraded to log4j2-2.16. It disables jndi lookups altogether by default. -Rahul On Wed, Dec 15, 2021 at 7:40 AM wrote: > Hi all, > > Looks like we are not done with log4j security problems. Someone has > recommendations about CVE-2021-45046? > > Eric Briere >
AW: Using join queries with synchronous filterCache is not supported
Thanks, We still used LRUCache in our config which seems to be deprecated, updating the config to use CaffeineCache seems to do the trick. Best Regards Jens Jens Viebig Software Developer o: +49 4307 8358 0 f: +49 4307 8358 699 jens.vie...@vitec.com www.vitec.com Legal Notice Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. Neither VITEC S.A. (66 Avenue des Champs Elysées – 75008 Paris - France) nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. VITEC GmbH, Lise-Meitner-Str. 15, 24223 Schwentinental Geschäftsführer/Managing Director: Philippe Wetzel HRB Plön 1584 / Steuernummer: 2029706365 / VATnumber: DE134878603 -Ursprüngliche Nachricht- Von: Mikhail Khludnev Gesendet: Mittwoch, 15. Dezember 2021 13:10 An: users@solr.apache.org Betreff: Re: Using join queries with synchronous filterCache is not supported Hello, Jens. Have you considered turning async=true for the cache? On Wed, Dec 15, 2021 at 1:49 PM Jens Viebig wrote: > Hi List, > Since upgrading from solr 8.8.2 to 8.11.0 we get the following error > message: > > Using join queries with synchronous filterCache is not supported! > Details can be found in Solr Reference Guide under > 'query-settings-in-solrconfig'. > > Looking at the commit history this was recently added: > > https://github.com/apache/solr/commits/2d395989017cc28473dbe60d9a1e9e9 > 301bf9112/solr/core/src/java/org/apache/solr/search/JoinQuery.java > > For now we needed to disable the filter cache completely on the main > core/index to make searches work. We are concerned about loss of > performance. > > Is there any documentation on how to correctly configure the filter > cache on 8.11.0 ? > > Best Regards > Jens > > Jens Viebig > Software Developer > o: > +49 4307 8358 0 > f: > +49 4307 8358 699 > jens.vie...@vitec.com > www.vitec.com > > Legal Notice > Unless expressly stated otherwise, this message is confidential and > may be privileged. It is intended for the addressee(s) only. Access to > this e-mail by anyone else is unauthorized. If you are not an > addressee, any disclosure or copying of the contents of this e-mail or > any action taken (or not taken) in reliance on it is unauthorized and > may be unlawful. If you are not an addressee, please inform the sender > immediately. Neither VITEC S.A. (66 Avenue des Champs Elysées – 75008 > Paris - France) nor any of its subsidiaries or affiliates shall be > liable for the message if altered, changed or falsified. VITEC GmbH, > Lise-Meitner-Str. 15, 24223 Schwentinental Geschäftsführer/Managing > Director: Philippe Wetzel HRB Plön 1584 / Steuernummer: 2029706365 / > VATnumber: DE134878603 > -- Sincerely yours Mikhail Khludnev
AW: Log4J saga (CVE-2021-45046)
Is there already an Idea when 8.11.1 is supposed to be released ? Jens Viebig Software Developer o: +49 4307 8358 0 f: +49 4307 8358 699 jens.vie...@vitec.com www.vitec.com Legal Notice Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this e-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. Neither VITEC S.A. (66 Avenue des Champs Elysées – 75008 Paris - France) nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. VITEC GmbH, Lise-Meitner-Str. 15, 24223 Schwentinental Geschäftsführer/Managing Director: Philippe Wetzel HRB Plön 1584 / Steuernummer: 2029706365 / VATnumber: DE134878603 -Ursprüngliche Nachricht- Von: Rahul Goswami Gesendet: Mittwoch, 15. Dezember 2021 13:58 An: users@solr.apache.org Betreff: Re: Log4J saga (CVE-2021-45046) We just upgraded to log4j2-2.16. It disables jndi lookups altogether by default. -Rahul On Wed, Dec 15, 2021 at 7:40 AM wrote: > Hi all, > > Looks like we are not done with log4j security problems. Someone has > recommendations about CVE-2021-45046? > > Eric Briere >
Does Solr 3.6.1 support FIPS 140-2
Hi everyone, Does anyone know if Solr 3.6.1 supports FIPS 140-2? Thanks Steve
Re: Log4J saga (CVE-2021-45046)
> > Is there already an Idea when 8.11.1 is supposed to be released ? This was discussed yesterday. Check the archives for the full explanation. Short version: can’t give a definite date but it will be no sooner than a week from now.
Re: Log4J saga (CVE-2021-45046)
Keep in mind that you can have more than one log4j-core-*.jar to patch. In my case: /opt/solr-8.4.0/server/lib/ext/log4j-core-2.11.2.jar /opt/solr-8.4.0/contrib/prometheus-exporter/lib/log4j-core-2.11.2.jar Thomas Op wo 15 dec. 2021 om 13:52 schreef Bernd Fehling < bernd.fehl...@uni-bielefeld.de>: > > Isn't the example with "zip -q -d ..." as reported in the CVE not working > for you? > > Regards > Bernd > > Am 15.12.21 um 13:40 schrieb e_bri...@videotron.ca: > > Hi all, > > > > Looks like we are not done with log4j security problems. Someone has > recommendations about CVE-2021-45046? > > > > Eric Briere > > >
Query on CVE-2021-45046
Hi, We've implemented this step "Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from https://logging.apache.org/log4j/2.x/security.html for /server/lib/ext. We would like to check if /contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be mitigated in this manner as well, assuming two different solutions: 1) we use Prometheus for solr, and 2) we do not use Prometheus for solr? Kind regards, Eunice CONFIDENTIALITY: This email is intended solely for the person(s) named and may be confidential and/or privileged. If you are not the intended recipient, please delete it, notify us and do not copy, use, or disclose its contents. Towards a sustainable earth: Print only when necessary. Thank you.
Re: running Solr 6.6 with OpenJDK 11?
On 12/15/21 12:57 AM, Bernd Fehling wrote: To get away from the Oracle License by switching from Java 8 to OpenJDK 8, do you have any observations or measurements? What I have seen says that OpenJDK 8 is solid. In the last few years, I have not had first-hand access to large-scale Solr installs. I am running one Solr install for myself, but it is extremely small. OpenJDK has worked well for that install. It's running Solr 8.11.0, with OpenJDK 11. I do use OpenjDK 8 to build Solr, and that does work without problems. It's been a while since I have run the test suite, but that also works with OpenJDK 8. Prior to Oracle changing the license for their implementation of Java, I would have recommended Oracle Java first, and OpenJDK second. Since the license change, most uses of Oracle Java require paying Oracle, so now I recommend OpenJDK. Bonus to that -- OpenJDK packages are available in most Linux distributions from distro repositories. I am in the process of downloading 6.6.6 so I can do some testing. Transfer speed from archive.apache.org is terrible, I should be done with the download in about 15 minutes. Thanks, Shawn
Re: Query on CVE-2021-45046
On 12/14/21 10:55 PM, Soh Jia Yu, Eunice wrote: We've implemented this step "Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class" from https://logging.apache.org/log4j/2.x/security.html for /server/lib/ext. Interesting way to eliminate the problem. That would certainly work. We would like to check if /contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be mitigated in this manner as well, assuming two different solutions: 1) we use Prometheus for solr, and 2) we do not use Prometheus for solr? Someone on our team looked into this. No user-provided strings are logged by this module, so it should not be vulnerable. But if you want to be thorough and absolutely sure, you can modify the log4j-core jar like you did for Solr. Thanks, Shawn
Re: Log4J saga (CVE-2021-45046)
That is fixed in log4j 2.16.0, included in Solr 8.11.1. wunder Walter Underwood wun...@wunderwood.org http://observer.wunderwood.org/ (my blog) > On Dec 15, 2021, at 4:40 AM, e_bri...@videotron.ca wrote: > > Hi all, > > Looks like we are not done with log4j security problems. Someone has > recommendations about CVE-2021-45046? > > Eric Briere
Re: Query on CVE-2021-45046
Hello, is it safe to simply replace the jars in the solr lib/ext folder with version 2.16 or are they hardcoded in scripts or meta-inf files ? Thanks — Ing. Andrea Vettori Responsabile Sistemi Informativi B2BIres s.r.l. > On 15 Dec 2021, at 17:32, Shawn Heisey wrote: > > On 12/14/21 10:55 PM, Soh Jia Yu, Eunice wrote: >> We've implemented this step "Otherwise, remove the JndiLookup class from the >> classpath: zip -q -d log4j-core-*.jar >> org/apache/logging/log4j/core/lookup/JndiLookup.class" from >> https://logging.apache.org/log4j/2.x/security.html for >> /server/lib/ext. > > Interesting way to eliminate the problem. That would certainly work. > >> We would like to check if >> /contrib/prometheus-exporter/lib/log4j-core-2.13.2.jar needs to be >> mitigated in this manner as well, assuming two different solutions: 1) we >> use Prometheus for solr, and 2) we do not use Prometheus for solr? > > Someone on our team looked into this. No user-provided strings are logged by > this module, so it should not be vulnerable. But if you want to be thorough > and absolutely sure, you can modify the log4j-core jar like you did for Solr. > > Thanks, > Shawn > >
Re: Query on CVE-2021-45046
On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote: Hello, is it safe to simply replace the jars in the solr lib/ext folder with version 2.16 or are they hardcoded in scripts or meta-inf files ? This appears to work correctly if the original version of log4j included was 2.14.1. I have done this and had no problems. I replaced it with 2.15.0 as 2.16.0 had not yet come out when I did that testing. But I have not tried it with Solr versions shipping with any log4j version other than 2.14.1, or with a 2.16.0 replacement. I have no idea whether that would work. If the log4j team have done a good job of keeping the API stable, I think it would work, but I do not have any knowledge about that. You would be better off asking the log4j project about API compatibility between versions. Thanks, Shawn
Re: Does Solr 3.6.1 support FIPS 140-2
On 12/15/21 7:01 AM, Steven White wrote: Does anyone know if Solr 3.6.1 supports FIPS 140-2? Solr 3.6.1 was announced on July 22, 2012. Over nine years ago. At that time, Solr itself didn't have any kind of encryption capability. If you want to enable encryption for that version of Solr, you need to set up encryption in the container that is running Solr. That version of Solr only required Java 5, but would probably work with versions up to Java 8. I am not sure about that, because I have not tested it. Current versions of Solr allow adding HTTPS encryption to Jetty without ever directly touching the Jetty config. Whether or not the encryption meets the standards of that FIPS document will be largely determined by the version of Java that you are running, since it is Java that actually does the encryption. Also be aware that the container that shipped with Solr 3.6.1 was Jetty 6, which is also extremely old. Thanks, Shawn
Re: running Solr 6.6 with OpenJDK 11?
On 12/15/21 9:14 AM, Shawn Heisey wrote: I am in the process of downloading 6.6.6 so I can do some testing. Transfer speed from archive.apache.org is terrible, I should be done with the download in about 15 minutes. Out of the box, Solr 6.6.6 refuses to start with Java 11. It actually reports that the Java version is too old! This is because Java went from version numbers like 1.8.0.292 to version numbers like 11.0.11 after Java 8. The start script in 6.x doesn't work with the new version numbers. I did an experiment, replacing the bin/solr script in 6.6.6 with the bin/solr script from 8.11.0 ... although I have not done extensive testing, this appears to work. It was able to start Solr, and was also able to start the cloud example, with "bin/solr -e cloud -noprompt". I can't guarantee that there isn't some kind of compatibility problem in the actual Solr code, but it looks promising. Thanks, Shawn
Re: running Solr 6.6 with OpenJDK 11?
On 2021-12-15 11:06 AM, Shawn Heisey wrote: ... I did an experiment, replacing the bin/solr script in 6.6.6 with the bin/solr script from 8.11.0 ... although I have not done extensive testing, this appears to work. It was able to start Solr, and was also able to start the cloud example, with "bin/solr -e cloud -noprompt". I can't guarantee that there isn't some kind of compatibility problem in the actual Solr code, but it looks promising. Anecdotally at least, Java's been the most stable over upgrades for us from half a dozen or so PLs (with Perl running a close second); I have Java code that's old enough to buy alcohol that's still running just fine w/o rebuilds. It's nowhere near as big and convoluted as Solr, but still... If it starts, there's a good chance it'll run just fine. It usually builds, too, if you ignore warnings about "new features" like generics etc. Dima
Re: Query on CVE-2021-45046
I would also encourage you to do the upgrade first on QA/Staging rather than directly on production, where possible. This could prevent nasty binary incompatibilities where the Solr build expects certain methods from the compiled log4j library, that mismatch with the upgraded jar. And a crashed offline production environment is definitely not better than a potentially vulnerable one :) Cheers -- Alessandro Benedetti Apache Lucene/Solr Committer Director, R&D Software Engineer, Search Consultant www.sease.io On Wed, 15 Dec 2021 at 16:54, Shawn Heisey wrote: > On 12/15/21 9:41 AM, Ing. Andrea Vettori wrote: > > Hello, is it safe to simply replace the jars in the solr lib/ext folder > with version 2.16 or are they hardcoded in scripts or meta-inf files ? > > > This appears to work correctly if the original version of log4j included > was 2.14.1. I have done this and had no problems. I replaced it with > 2.15.0 as 2.16.0 had not yet come out when I did that testing. > > But I have not tried it with Solr versions shipping with any log4j > version other than 2.14.1, or with a 2.16.0 replacement. I have no idea > whether that would work. If the log4j team have done a good job of > keeping the API stable, I think it would work, but I do not have any > knowledge about that. You would be better off asking the log4j project > about API compatibility between versions. > > Thanks, > Shawn > >
Log4J saga (CVE-2021-45046)
I find these files in my solr install ./server/lib/ext/log4j-core-2.11.0.jar ./server/lib/ext/log4j-1.2-api-2.11.0.jar ./server/lib/ext/log4j-api-2.11.0.jar ./server/lib/ext/log4j-slf4j-impl-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-core-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-api-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.11.0.jar If I replace them all with version 2.16 will that clear this up? DO I have to change anything else? thanks, Scott
Re: Log4J saga (CVE-2021-45046)
That should be sufficient based on our current understanding of the situation, yes. On Wed, Dec 15, 2021 at 12:53 PM Scott Derrick wrote: > I find these files in my solr install > > ./server/lib/ext/log4j-core-2.11.0.jar > ./server/lib/ext/log4j-1.2-api-2.11.0.jar > ./server/lib/ext/log4j-api-2.11.0.jar > ./server/lib/ext/log4j-slf4j-impl-2.11.0.jar > ./contrib/prometheus-exporter/lib/log4j-core-2.11.0.jar > ./contrib/prometheus-exporter/lib/log4j-api-2.11.0.jar > ./contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.11.0.jar > > If I replace them all with version 2.16 will that clear this up? DO I > have to change anything else? > > thanks, > > Scott > >
Re: Log4J saga (CVE-2021-45046)
On 12/15/21 11:53 AM, Scott Derrick wrote: I find these files in my solr install ./server/lib/ext/log4j-core-2.11.0.jar ./server/lib/ext/log4j-1.2-api-2.11.0.jar ./server/lib/ext/log4j-api-2.11.0.jar ./server/lib/ext/log4j-slf4j-impl-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-core-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-api-2.11.0.jar ./contrib/prometheus-exporter/lib/log4j-slf4j-impl-2.11.0.jar If I replace them all with version 2.16 will that clear this up? DO I have to change anything else? As stated on another thread ... this MIGHT be a viable option. But without actually trying it, it's difficult to say for sure. I was able to successfully start Solr 8.11.0 after replacing its log4j 2.14.1 jars with 2.15.0. That's an upgrade of one minor version. You're talking about upgrading across five minor versions. That's a lot more likely to cause issues. What I would recommend you do for a version that old is modify the log4j-core jar in place to remove the JndiLookup class, as documented on the log4j website. zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class https://logging.apache.org/log4j/2.x/security.html As for whether you need to do that for prometheus-exporter ... you would only need to do that if you are actually using that program. You would likely know if you're doing that, it doesn't get started unless somebody runs it explicitly. Solr devs have stated that they do not think the prometheus exporter is vulnerable, as it should never send any user-created string to the logging implementation. But if you're using it, it's better to do mitigation even if it's not vulnerable. Thanks, Shawn
