It doesn't seem that bad, yet I know some people will freak. According
to the proposal, it will say this:
WARNING: A command line option has enabled the Security Manager
WARNING: The Security Manager is deprecated and will be removed in a
future release
I think the modularization goal is great,
I wasn't actually making a request to specifically upgrade there. Sorry if
you took it that way. Please don't shoot :) I was just stating a general
point relating to a peeve of mine (which was why I replied to the list for
possible discussion not on the issue). I actually fault Java for the
situati
In the case of forbiddenapis you have to shade as for example ASM is
incompatible to each oder and for example Gradle ships with its own outdated
versions.
Forbiddenapis is my responsibility and I can decide if and what I'd like to
shade.
Generally the recent log4j discussion and organizations
Hi Anna,
Thanks for sharing your discovery!
I agree with your analysis that the condition currently never evaluates to
true. Due to how the ReRankCollector calls the rescore method, and have just
opened https://issues.apache.org/jira/browse/SOLR-15869 to expand test coverage
to capture the beh
Hi,
If your organization requires, you can do that manually, as described in the
security advisory. Log4j 2.17 is backwards compatible down to 2.0.
Delete the old jar files, download newer versions from Maven Central (or log4j
website all in one) and drop them where the older version were befor
That is the case here at Adobe. Even though we have multiple mitigations in
place for Solr (configuration, Java 11), we will be required to upgrade to
Log4J version 2.17.
From: Gus Heck
Reply-To: "dev@solr.apache.org"
Date: Tuesday, December 21, 2021 at 1:21 PM
To: "dev@solr.apache.org"
Subje
Except stone-age deps are dependencies that are not updated, and may
contain vulnerabilities. Less important for build things like RAT since the
risk there is contained within ASF and not to our users, and the inputs are
much more tightly controlled, but not zero risk.
I really don't like shade/sh
The test OverseerCollectionConfigSetProcessorTest has failed 4 out of the last
5 runs, and last stable build is almost 2 days ago.
The failure does not reproduce locally so is likely some timing issue?
I filed https://issues.apache.org/jira/browse/SOLR-15868 as a blocker. Will
@BadApple this tes
On 12/21/21 2:18 PM, Gus Heck wrote:
For what it's worth, I'm seeing IT depts not wanting to track
exceptions to the rule (such as solr) and requiring the library
upgrades period.
Earlier today I tried a jar upgrade from 2.11.0 to 2.17.0 on Solr
7.5.0. It was successful. I made sure that th
