Scott,
Any update on this? We are being pinged again.
Ralph
> On Nov 7, 2020, at 3:48 PM, Scott Deboy wrote:
>
> If I recall correctly, log4cxx supports the log4j xml format over tcp.
>
> Scott
>
> On Sat, Nov 7, 2020, 11:49 AM Matt Sicker wrote:
>
>> It would limit the supported classes
It looks like it will do that - there is an xmllayout that I haven't
paid too much attention to in the past.
Part of this is that I really need to update some of the documentation
for log4cxx to show the possible options for how to do things. The
chainsaw documentation could also be updated as
If I recall correctly, log4cxx supports the log4j xml format over tcp.
Scott
On Sat, Nov 7, 2020, 11:49 AM Matt Sicker wrote:
> It would limit the supported classes to a safe allowlist. Ideally, we
> should be using both standardized logging formats (including de facto
> standards like GELF)
It would limit the supported classes to a safe allowlist. Ideally, we
should be using both standardized logging formats (including de facto
standards like GELF) as well as developing a proper binary logging
format proposed a few years ago.
On Sat, 7 Nov 2020 at 13:45, Robert Middleton wrote:
>
>
Chainsaw supports log4j1 xml format via tcp or local file, and supports
parsing of arbitrary plain text formats via LogFilePatternReceiver (tailing
of log files, including via ssh).
Scott
On Sat, Nov 7, 2020, 11:45 AM Robert Middleton wrote:
> Would this be a total removal of the Java
Would this be a total removal of the Java deserialization? I ask
because I think I've used that before with log4cxx to send log
messages to chainsaw.
Alternatively, I guess the better question is "should chainsaw support
structured log messages input?" I know that there was something about
Any use of deserialization over the network (or from untrusted input
sources in general) should use an allowlist of deserializable classes.
That's what we did in log4j2's serialized log event receiver code a
few years ago, for example:
https://github.com/apache/logging-log4j2/commit/5dcc192
I assume reverse-connect is still fine (SocketHubAppender/Receiver),
as Chainsaw is being configured to reach a specific (assumed trusted)
endpoint, yes?
On 11/6/20, Scott Deboy wrote:
> Holy cow. February?
>
> I have zero problem with us nuking the object serialization receiver
> support. I
Holy cow. February?
I have zero problem with us nuking the object serialization receiver
support. I think the vfs receiver is the way to go, still works great.
I can remove the code in Chainsaw master.
Hope all are well, good to hear from you!
Scott
On Fri, Nov 6, 2020, 7:53 PM Ralph Goers
Great to hear from you again! I don’t know if you saw it but there is a
Chainsaw related email on Feb 12 of this year in the private list that you
should take a look at if you are planning on doing some work on Chainsaw.
Ralph
> On Nov 6, 2020, at 5:57 PM, Scott Deboy wrote:
>
> Hey all,
>
Hey, great to hear from you again!
On Fri, Nov 6, 2020 at 18:57 Scott Deboy wrote:
> Hey all,
>
> Long time.
>
> I decided to work through the pom ugliness and a couple of swing
> degradation issues in Chainsaw.
>
> I found an ASL2 Mac dmg creation maven plugin, and it works well on my
> Mac,
11 matches
Mail list logo