Hi Gary, Even this could work theoretically, but it does in reality not: in PatterLayout.format the Converter (by default the LineSeparatorPatternConverter) is called _before_ the replace is called (in PatterLayout.toSerializable), resulting in following: the "\r\n" added by LineSeparatorPatternConverter.format is simply replaced, resulting in a log file containing no line feeds.
Besides this tiny bug, I still wonder: if we want proper secure file based logging, should we address Log Forgery all times by introducing a custom replacement pattern? I do recall Remko saying "I worry about the performance impact" and "The application knows which points are vulnerable and it knows what form the input takes so it is best positioned to protect itself" - all this lets me think that the main reason for concerns about updating Log4J for protection is performance. So far I had 3 recommendations on how to fix: Remko was suggesting to dig out linefeeds on the caller side, as then it can be selectively applied - no doubt it would be the most performant - I just wonder if in a complex real-life application (as for example in our case) it is really easy and straightforward to track, where a string is coming from (was maybe mixed up with other user input, might come indirectly via database, from a call via an untrusted source etc etc) As with the two other proposals, it would introduce an additional layouting, either custom (which would be maybe redundant to be implemented every time someone uses Log4J) or by configuring PatternLayout (which is done with regex - what I would consider more questionable from a performance perspective than a simple hand-coded replace)... I am still somewhat insistent on that maybe a configuration option for any affected appenders (e.g. FileAppender) would be handy - so if people want to go for so much performance, they can turn off linefeed elimination, and risk that their logs will be tampered with. I know I am not in a good position with my plea, as I have not been an active developer of Log4J so far - but as I am a user of this, I am somewhat enthusiastic about making it superior, so I would give it a last try on promoting this idea :) Cheers, Gabor ---------------------------------------------------------------------- > Can you do what you want with the PatternLayout's replace feature? > > Gary > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
