Thanks Franz! All the best for 2022. Gary
On Thu, Dec 30, 2021, 09:17 Franz van Betteraey <fr...@van-betteraey.de> wrote: > 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 > >
