Agreed that the feature should be purged entirely. I turned it off by default with no global enablement on release-2.x (shipped in 2.15).
-ck > On Dec 11, 2021, at 09:13, Mikael Ståldal <[email protected]> wrote: > > I would say that log messages and log message parameter are as much (or as > little) controlled by the application. I don't think it make sense to see > them differently from a security perspective. > > Just as some code might do: > logger.info("some message {}", userInput); > > Other code might do: > logger.info("some message " + userInput); > > And if you use the Scala API, parameters get merged into the log message > since you would use Scala string interpolation: > https://logging.apache.org/log4j/scala/index.html > > (There might also exist 3rd-party language bindings or other wrappers of > Log4j where parameters are merged into into the log message before passed to > Log4j.) > > I think that lookups should be removed from both log message and log message > parameters. > > >> On 2021-12-10 11:50, Remko Popma wrote: >> I would say no. Lookups are very powerful and useful. >> We could consider removing JNDI lookups. >> The biggest problem however is that the lookups are applied to the logging >> message *parameters*. >> The logging message is controlled by the application, so any lookups there >> should be fine or at least any problems can be found during review/audit. >> I cannot imagine a scenario where doing lookups against the message >> parameters is useful. >> There could be such a scenario, but then the application should do this >> explicitly, with something like >> logger.info("some message {}", doExplicitLookup(param)); >> I haven't looked at the fix in enough detail, but removing lookups in >> logging message parameters sounds reasonable. >> Not sure how easy it would be to implement this though. >>> On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı <[email protected]> wrote: >>> Shall we completely remove message lookups (which are only used by >>> PatternLayout) in master? >>>
