On Thu, Oct 12, 2023, at 20:44, Piotr P. Karwasz wrote:
> However we should consider properly documenting PatternLayout: there
> should be a warning reminding users that while it is technically
> possible to generate a proper JSON or XML using this layout it is not
> the suggested way.
No object
Hi Christian,
On Thu, 12 Oct 2023 at 20:11, Christian Grobmeier wrote:
> I assume we could quickly make log4j safer by adding an encoder, as suggested
> by Vladimir, so my question is, why should we not do it?
Yes, we can easily add an `outputFormat` attribute to the pattern
layout that accepts
out of 89 define a layout that is not a pattern
> layout: one repo a JSONLayout and one a StackdriverLayout.
>
>
> -Original Message-----
> From: Volkan Yazıcı
> Sent: Wednesday, 11 October 2023 11:32
> To: dev@logging.apache.org
> Subject: Re: [log4j] Improving lo
ayout. Only two repos out of 89
define a layout that is not a pattern layout: one repo a JSONLayout and one a
StackdriverLayout.
-Original Message-
From: Volkan Yazıcı
Sent: Wednesday, 11 October 2023 11:32
To: dev@logging.apache.org
Subject: Re: [log4j] Improving log4j security
Your use
Your use case sounds to me as follows: "I want to use `PatternLayout` for
exchanging data between two systems and ... [it is insecure.]" (Please
correct me if I am wrong.) My answer is: "Don't".
`PatternLayout` is not designed to be machine-readable. If I am not
mistaken, there is not even a stand
Hi Volkan,
Let me try to clarify. The goal/usecase is not to log as an HTML document. We
are assuming a typical text-based log here. Yet, in practice, the logs will be
processed by a variety of systems, including web-based ones, which may have
various vulnerabilities. These vulnerabilities can
;>>
>>> 3. The current encoders encode all structured data (like the complete
>>> exception stacktrace) and not just the injection-prone parts (i.e., the
>>> exception message). This means I cannot replace the insecure layout above
>>> with the secure layout
>
;> exception stacktrace) and not just the injection-prone parts (i.e., the
>> exception message). This means I cannot replace the insecure layout above
>> with the secure layout
>>
>>
>>
>> without changing how logs are parsed (as the stack frames wil
one here interested in
> that? Questions and comments are welcome as well.
>
> Thanks,
> Vladimir
>
>
> -Original Message-
> From: Piotr P. Karwasz
> Sent: Thursday, 5 October 2023 22:06
> To: dev@logging.apache.org; Klebanov, Vladimir
> Subject: Re: [log4j] Improv
stions and comments are welcome as well.
Thanks,
Vladimir
-Original Message-
From: Piotr P. Karwasz
Sent: Thursday, 5 October 2023 22:06
To: dev@logging.apache.org; Klebanov, Vladimir
Subject: Re: [log4j] Improving log4j security
[You don't often get email from piotr.karw...@gmail.com.
Hello Vladimir,
I am not sure if you received Piotrs message below - please let us know :)
Kind regards,
Christian
--
The Apache Software Foundation
V.P., Data Privacy
On Thu, Oct 5, 2023, at 22:05, Piotr P. Karwasz wrote:
> Hi Vladimir,
>
> On Thu, 5 Oct 2023 at 21:47, Klebanov, Vladimir
> wr
Hi Vladimir,
On Thu, 5 Oct 2023 at 21:47, Klebanov, Vladimir
wrote:
> I would like to contribute some code in order to make log4j usage more
> secure. I have now sent two emails to the log4j security team but did not
> receive a response. Is anybody here interested? How can we discuss this
> f
12 matches
Mail list logo