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
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
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
>
> You
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 case sounds
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
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
. 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
>>>
>>>
trace) 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 will not be
>> separat
sted 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] Improving log4j secur
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. Learn why
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
>
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
>
Hello,
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 further?
Thanks,
Vladimir
13 matches
Mail list logo
