Dear David, Gary and especially Carter,
Thank you for taking the time to answer my question about the
StrSubstitutor. I finally had time to look at the tips today and they
were very helpful.
I wish you - and the whole log4j team - a good start into 2022 and a
great year.
- Franz
Am 23.12.2021 um 21:56 schrieb Gary Gregory:
Excellent write up!
Gary
On Thu, Dec 23, 2021, 10:19 Carter Kozak <cko...@ckozak.net> wrote:
I've put together a more thorough document here:
https://github.com/apache/logging-log4j2/blob/release-2.x/docs/2.17.0-interpolation.md
On Wed, Dec 22, 2021, at 11:38, Carter Kozak wrote:
This is a great question, and something I'm working on documenting today.
The relevant change in 2.17.0 is
https://github.com/apache/logging-log4j2/commit/806023265f8c905b2dd1d81fd2458f64b2ea0b5e
Outside of evaluating the configuration itself, we no longer recursively
evaluate substitution results. This means that
config.getStrSubstitutor().replace(event, "${event:Message}") for the event
'log.info("Hello, ${lower:WORLD}")' will evaluate to the literal string
"Hello, ${lower:WORLD}" where previous releases would incorrectly evaluate
to "Hello, world". I would certainly recommend writing unit tests in your
project to verify this behavior as well :-)
-ck
On Wed, Dec 22, 2021, at 11:29, Franz van Betteraey wrote:
Sorry Gary for not being precise enough. Yes, I am using the latest
patched version 2.17.0 and hope to benefit from the security patches.
My custom layout class extends AbstractStringLayout and the
configuration is injected via the @PluginConfiguration parameter of
the
PluginFactory method.
@PluginFactory
public static MyCustomLayout createLayout(
@PluginConfiguration final Configuration config, ...)
I than get the StrSubstitutor from config.getStrSubstitutor(). My
custom
layout allows to specify/configure a list of lookups like
"${event.ThreadName}" or "${date:yyyy-MM-dd'T'HH:mm:ss.SSSZ}" and
resolves these (one by one) via 'strSubstitutor.replace'.
I do not call this method on "${event:Message}" placeholder. Here I
just
use 'logEvent.getMessage().getFormattedMessage()' to get the message
text.
All lookup placeholder are specified via configuration (thus in my
hand).
My hope now is that the implemented security patches (disabled Jndi
Appender, substitution recursion, etc.) will also be effective in this
case of use.
Am 22.12.2021 um 13:45 schrieb Gary Gregory:
Since you don't specify which version you are using I will assume
that you
are using our latest patched version which is 2.17.0, the best and
safest
choice.
Your description is also too vague: The
method StrSubstitutor.replace(LogEvent, String) is an instance
method and
you do not describe how you created the StrSubstitutor, so there is
no way
for me to tell what is safe and what is not
Gary
On Wed, Dec 22, 2021 at 5:25 AM Franz van Betteraey <
fr...@van-betteraey.de>
wrote:
Dear Log4j Team,
first of all thank you for your tireless efforts around the project,
which I appreciate very much.
My question is: Is it safe to call 'StrSubstitutor.replace(final
LogEvent event, final String source)' in a custom Layout class that
inherits from AbstractStringLayout? The StrSubstitutor object is
derived
via the configuration and the 'source' string might contain any
lookup
placeholder.
It is not clear to me if the defense mechanisms against the current
security vulnerabilities take effect before such a call and
prevents the
framework on calling this method, or if the call is still secure
and the
defense happens afterwards (e.g. by not instantiating lookups).
I thank you for any advice and wish you happy and peaceful holidays.
Franz
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
-ck
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
