Ran the smoke tested, and it passed.
SUCCESS! [1:21:47.769507]
+1
On Wed, Dec 15, 2021 at 9:28 AM Mike Drob wrote:
> +1 (binding)
>
> ran smoke tester - unit tests passed the first time but timed out
> downloading artifacts from maven. reran a second time, modifying the smoke
> test script to
+1 (binding)
ran smoke tester - unit tests passed the first time but timed out
downloading artifacts from maven. reran a second time, modifying the smoke
test script to not run solr tests (again) and the script passed.
started up a solr server from the unpacked download and verified it against
a
+1 (binding) ~ just ran smoke tester this time
SUCCESS! [1:16:20.247006]
On Tue, Dec 14, 2021 at 7:36 AM Jan Høydahl wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.11.1
>
> The artifacts can be downloaded from:
>
Perhaps we could tweak it to say that the system property fix is sufficient
*for Solr* (i.e. not imply that it is a valid work around for all cases)
On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler wrote:
> The other attack vectors are also not possible with Solr:
>
> - Logger.printf("%s",
Let's mention this change in release note only.
Uwe
Am 14. Dezember 2021 22:35:27 UTC schrieb "Jan Høydahl" :
>The only question I have is regarding Lucene, which lists (no changes).
>There IS one change though - it ships with log4j 2.16, but I guess that's only
>relevant for Luke since
The other attack vectors are also not possible with Solr:
- Logger.printf("%s", userInput) is not used
- custom message factory is not used
Uwe
Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler :
>It is still a valid mitigation.
>
>Mike Drobban I explained it. MDC is the other attack
+1
Jan, thank you for being the release manager!
Everyone, I know ppl are busy, maybe haven't slept or ate, but
please/begging let's just test out this RC, report back with VOTEs,
and get these fixes to the users as quick as possible. Let's take care
of addressing issues like this for the
It is still a valid mitigation.
Mike Drobban I explained it. MDC is the other attack vector and that's not an
issue with Solr.
Please accept this, just because the documentation of log4j changes, there's no
additional risk. We may update the mitigation to mention that in Solr's case
the
Hi,
Solr does use MDC (the %X pattern), but the values are not user generated and
all come from config files and are enforced to comply to certain formats (e.g.,
no $ possible). Shard, replica, collection names are sanitized.
In short all fine, no need to change the mitigation instructions.
Ok.
But FTR - apache/log4j has discredited just setting the system property as a
mitigation measure, so I still think the SOLR security-page should be changed
to not list this as a valid mitigation:
https://logging.apache.org/log4j/2.x/security.html
"Older (discredited) mitigation measures
The MDC Patterns used by solr are for the collection, shard, replica, core
and node names, and a potential trace id. All of those are restricted to
alphanumeric, no special characters like $ or { needed for the injection.
And trying to access a collection that didn’t exist Returns 404 without
The only question I have is regarding Lucene, which lists (no changes).
There IS one change though - it ships with log4j 2.16, but I guess that's only
relevant for Luke since everyone else consume Lucene through maven. Is it worth
a mention in the Lucene release-notes
Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to mitigate
the log4j vulnerability.
See https://github.com/kmindi/log4shell-vulnerable-app
“So even with LOG4J_FORMAT_MSG_NO_LOOKUPS true version 2.14.1 of log4j is
vulnerable when using ThreadContextMap in PatternLayout.”
Please vote for release candidate 1 for Lucene/Solr 8.11.1
The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
You can run the smoke tester directly (from a fresh branch_8_11 checkout), with
this
Yes, I'm building with log4j 2.16 now.
Will BadApple a few tests, yes..
Jan
> 14. des. 2021 kl. 10:39 skrev Uwe Schindler :
>
> I think we should update log4j to 2.16.0:
>
> Reason: It has all JNDI and expansion of ${...} in log messages disabled. So
> we also prevent that people enable this
I think we should update log4j to 2.16.0:
Reason: It has all JNDI and expansion of ${...} in log messages disabled. So we
also prevent that people enable this with buggy logging configs.
Uwe
-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de
>
Yes, please use 2.16.
Uwe
Am 14. Dezember 2021 00:00:49 UTC schrieb Mike Drob :
>There's been a log4j 2.16 release as well, should we pick that one up if
>your next attempt fails?
>
>https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
>
>On Mon, Dec 13, 2021 at 5:58 PM Jan Høydahl
17 matches
Mail list logo
