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 <mik...@staldal.nu> 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ı <vol...@yazi.ci> wrote:
>>> Shall we completely remove message lookups (which are only used by
>>> PatternLayout) in master?
>>>
