Re: [log4j] Improving log4j security
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 > 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 >> further? > > Both times (10 Aug 2023, 23:19 and 29 Aug 2023, 20:49) we sent an > answer to your address at sap.com. > > Anyway the general consensus was that the issue with generating HTML > using PatternLayout does not constitute a security problem and you can > discuss it on this mailing list or file an issue in Github issues. > > Piotr
Re: [chainsaw] What is necessary for a 2.2 release?
geson seems to do a good job, like Jackson (same JSR).
I'd like to move forward with JSON format for storing properties.
I am not sure what the status currently is, if Scott is still working on it :)
I could also make some kind of proposal or so for storing properties
On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
> I think persisting to json format makes sense/would be easy to consume
> with tools if needed.
>
> On 10/2/23, Robert Middleton wrote:
>>> OK. Do you think something based on Jackson would be good? It's JSON
>>> though.
>>
>> We already have a dependency on genson for JSON parsing, so if we
>> really want to use JSON that would make the most sense. Commons
>> config can read/write XML; currently I just have it configured to do
>> properties files. I think we can write our own reader/writer as well,
>> but ultimately I don't think that there is anything special that we
>> need that commons config doesn't provide us out of the box.
>>
>> -Robert Middleton
>>
>> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker wrote:
>>>
>>> Jackson makes for a good library here because it also supports several
>>> data formats (YAML, XML, HOCON, and all sorts of others, both textual and
>>> binary) and is fairly extensible for hooking any custom serialization or
>>> deserialization logic you need. Given the desire to avoid Java
>>> serialization, it is perfectly reasonable to avoid XStream as that’s
>>> basically Java serialization using XML with all the pitfalls that entails
>>> (I dealt with this fairly extensively back in the Jenkins project which
>>> used an old fork of XStream for managing config files and state).
>>>
>>> I haven’t used Commons Configuration before, but it seems fairly
>>> appropriate for this sort of thing as well.
>>>
>>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier
>>> > wrote:
>>> >
>>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
>>> >> At least two reasons I can think of:
>>> >> 1. Xstream doesn’t work on all java versions as you saw
>>> >> 2. Simplify by using the commons config instead of rolling our own.
>>> >>
>>> >> Each tab should now have just one config file, the idea being that you
>>> >> can
>>> >> now share config files between people. Before each tab had at least
>>> >> two(maybe three) files. One was the xml config, one was a java
>>> >> serialized
>>> >> map. Removing the java serialization is important.
>>> >
>>> > OK. Do you think something based on Jackson would be good? It's JSON
>>> > though.
>>> >
>>> > From an example:
>>> >
>>> > ObjectMapper objectMapper = new ObjectMapper();
>>> > Car car = new Car("yellow", "renault");
>>> > objectMapper.writeValue(new File("target/car.json"), car);
>>> >
>>> > We could wrap this in some kind of class and make it accessible per
>>> > "tab" (or whatever).
>>> >
>>> >
>>> >>
>>> >> -Robert Middleton
>>> >>
>>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
>>> >>
>>> >> wrote:
>>> >>
>>> >>>
>>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
>>> Some(most?) of the settings should be saved:
>>>
>>> >>> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
>>>
>>> The stuff that is commented out should just be the old saving code
>>> that
>>> used XStream to save the data out.
>>> >>>
>>> >>> You made it using this commit (thank you, its easy to track):
>>> >>>
>>> >>> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
>>> >>>
>>> >>> One question: why did we remove Xstream? it seem there was an update
>>> >>> late
>>> >>> 2022 to address some security.
>>> >>> Should we just re-enable it or was there other reasons too?
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>>
>>> -Robert Middleton
>>>
>>> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
>>> >>
>>> wrote:
>>>
>>> >
>>> > On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
>>> >> The ability to route events to tabs is a core feature in the code
>>> >> -
>>> >> that's how Chainsaw log messages end up in a Chainsaw-specific tab
>>> >> -
>>> >> but the ability to control that routing via a 'routing expression'
>>> >> was
>>> >> nuked from app-wide preferences - another thing we should bring
>>> >> back.
>>> >>
>>> >> It looks like we lost a lot of prefs, both panel-level and
>>> >> app-wide
>>> > prefs.
>>> >
>>> > Yes, I think all prefs are somehow gone. At least everything that
>>> > is
>>> > writes to a file seems to be commented.
>>> > I didn't remove those things yet, as they seemed to big and I
>>> > didn't
>>> > understand well how they'd work or how I would test (I lack the
>>> >>> knowledge
>>> > of how the UI should operate but only see what is there now)
>>> >
>>> >
>>> >>
>>> >> Scott
>>> >>
>>> >> On 10/1/23
Re: [chainsaw] What is necessary for a 2.2 release?
I started but haven't had much time this week. The UI updates driven by
settings changes are most of what I have left.
On Sun, Oct 8, 2023, 2:17 PM Christian Grobmeier
wrote:
> geson seems to do a good job, like Jackson (same JSR).
> I'd like to move forward with JSON format for storing properties.
>
> I am not sure what the status currently is, if Scott is still working on
> it :) I could also make some kind of proposal or so for storing properties
>
> On Tue, Oct 3, 2023, at 01:20, Scott Deboy wrote:
> > I think persisting to json format makes sense/would be easy to consume
> > with tools if needed.
> >
> > On 10/2/23, Robert Middleton wrote:
> >>> OK. Do you think something based on Jackson would be good? It's JSON
> >>> though.
> >>
> >> We already have a dependency on genson for JSON parsing, so if we
> >> really want to use JSON that would make the most sense. Commons
> >> config can read/write XML; currently I just have it configured to do
> >> properties files. I think we can write our own reader/writer as well,
> >> but ultimately I don't think that there is anything special that we
> >> need that commons config doesn't provide us out of the box.
> >>
> >> -Robert Middleton
> >>
> >> On Mon, Oct 2, 2023 at 5:14 PM Matt Sicker wrote:
> >>>
> >>> Jackson makes for a good library here because it also supports several
> >>> data formats (YAML, XML, HOCON, and all sorts of others, both textual
> and
> >>> binary) and is fairly extensible for hooking any custom serialization
> or
> >>> deserialization logic you need. Given the desire to avoid Java
> >>> serialization, it is perfectly reasonable to avoid XStream as that’s
> >>> basically Java serialization using XML with all the pitfalls that
> entails
> >>> (I dealt with this fairly extensively back in the Jenkins project which
> >>> used an old fork of XStream for managing config files and state).
> >>>
> >>> I haven’t used Commons Configuration before, but it seems fairly
> >>> appropriate for this sort of thing as well.
> >>>
> >>> > On Oct 2, 2023, at 1:43 PM, Christian Grobmeier <
> grobme...@apache.org>
> >>> > wrote:
> >>> >
> >>> > On Mon, Oct 2, 2023, at 16:15, Robert Middleton wrote:
> >>> >> At least two reasons I can think of:
> >>> >> 1. Xstream doesn’t work on all java versions as you saw
> >>> >> 2. Simplify by using the commons config instead of rolling our own.
> >>> >>
> >>> >> Each tab should now have just one config file, the idea being that
> you
> >>> >> can
> >>> >> now share config files between people. Before each tab had at least
> >>> >> two(maybe three) files. One was the xml config, one was a java
> >>> >> serialized
> >>> >> map. Removing the java serialization is important.
> >>> >
> >>> > OK. Do you think something based on Jackson would be good? It's JSON
> >>> > though.
> >>> >
> >>> > From an example:
> >>> >
> >>> > ObjectMapper objectMapper = new ObjectMapper();
> >>> > Car car = new Car("yellow", "renault");
> >>> > objectMapper.writeValue(new File("target/car.json"), car);
> >>> >
> >>> > We could wrap this in some kind of class and make it accessible per
> >>> > "tab" (or whatever).
> >>> >
> >>> >
> >>> >>
> >>> >> -Robert Middleton
> >>> >>
> >>> >> On Mon, Oct 2, 2023 at 6:12 AM Christian Grobmeier
> >>> >>
> >>> >> wrote:
> >>> >>
> >>> >>>
> >>> >>> On Mon, Oct 2, 2023, at 02:55, Robert Middleton wrote:
> >>> Some(most?) of the settings should be saved:
> >>>
> >>> >>>
> https://github.com/apache/logging-chainsaw/blob/5ccb3c8e55dffd4361c549c3bcdac3f3675f79e5/src/main/java/org/apache/log4j/chainsaw/prefs/SettingsManager.java#L191
> >>>
> >>> The stuff that is commented out should just be the old saving code
> >>> that
> >>> used XStream to save the data out.
> >>> >>>
> >>> >>> You made it using this commit (thank you, its easy to track):
> >>> >>>
> >>> >>>
> https://github.com/apache/logging-chainsaw/commit/75bedf98665188eef4d13e4bfbb4b0dae456f65e
> >>> >>>
> >>> >>> One question: why did we remove Xstream? it seem there was an
> update
> >>> >>> late
> >>> >>> 2022 to address some security.
> >>> >>> Should we just re-enable it or was there other reasons too?
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>>
> >>> -Robert Middleton
> >>>
> >>> On Sun, Oct 1, 2023 at 3:39 PM Christian Grobmeier
> >>> >>>
> >>> wrote:
> >>>
> >>> >
> >>> > On Sun, Oct 1, 2023, at 21:28, Scott Deboy wrote:
> >>> >> The ability to route events to tabs is a core feature in the
> code
> >>> >> -
> >>> >> that's how Chainsaw log messages end up in a Chainsaw-specific
> tab
> >>> >> -
> >>> >> but the ability to control that routing via a 'routing
> expression'
> >>> >> was
> >>> >> nuked from app-wide preferences - another thing we should bring
> >>> >> back.
> >>> >>
> >>> >> It looks like we lost a lot of prefs, both panel-level and
> >>> >> app-wide
> >>> > prefs.
> >>> >
> >>> > Yes, I t
