Note that XML can have problems of its own. Using DTDs can create security vulnerabilities. These day some form of JSON or a binary protocol such as protobuf would be preferred. The main thing is that the payload not contain information regarding the classes to instantiate (as Java serialization does) and that it doesn’t reference URLs that are automatically contacted.
Ralph > On Nov 7, 2020, at 4:28 PM, Robert Middleton <osfan6...@gmail.com> wrote: > > 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 well, but I haven't > used it enough to know where to start. > > -Robert Middleton > > On Sat, Nov 7, 2020 at 5:49 PM Scott Deboy <scott.de...@gmail.com> wrote: >> >> If I recall correctly, log4cxx supports the log4j xml format over tcp. >> >> Scott >> >> On Sat, Nov 7, 2020, 11:49 AM Matt Sicker <boa...@gmail.com> 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) as well as developing a proper binary logging >>> format proposed a few years ago. >>> >>> On Sat, 7 Nov 2020 at 13:45, Robert Middleton <osfan6...@gmail.com> wrote: >>>> >>>> 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 >>>> log4j2 supporting GELF a while ago - perhaps that could be a good >>>> standard for sending log messages? >>>> >>>> -Robert Middleton >>>> >>>> On Sat, Nov 7, 2020 at 12:27 PM Matt Sicker <boa...@gmail.com> wrote: >>>>> >>>>> 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 >>>>> (CVE-2017-5646). >>>>> >>>>> On Sat, 7 Nov 2020 at 11:12, Scott Deboy <scott.de...@gmail.com> >>> wrote: >>>>>> >>>>>> 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 <scott.de...@gmail.com> wrote: >>>>>>> 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 < >>> ralph.go...@dslextreme.com> >>>>>>> wrote: >>>>>>> >>>>>>>> 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 <scott.de...@gmail.com> >>> 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, if anyone cares to try it out please do. >>>>>>>>> >>>>>>>>> Pushing changes to master shortly. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>> >
