Re: Google OSS-Fuzz

> I am tinkering with the idea of a Kickstarter-like initiative to sign up > for this. Maybe as a 2-months-long gig? > That sounds like it could be a GSoC thing(if nobody else is interested). The ASF has participated a number of times before. -Robert Middleton

Re: Google OSS-Fuzz

OSS-Fuzz would be very interesting to try out. We've tried using it in Commons, and so far, it's helped discover some bugs in commons-imaging (several binary file formats) and commons-compress (also several binary file formats). I'm the current contact point in Commons for our fuzzing setup, though

Re: Google OSS-Fuzz

This all sounds great. On top of real issues, I am sure this will present exceptions being thrown here and there where we can make at the very least said exceptions carry meaningful messages instead of a mysterious IOOB or AIOBE. I guess it all depends what I want to do with my nights and weekend

Re: [DISCUSS] Support 'log4j.rootLogger=INFO,Console' configuration grammar in log4j2

Yeah, that syntax is better although it doesn’t solve the multiple appender refs case either. LoggerConfig accepts a List so it would seem that if we modify LoggerConfig to add another attribute that is a string that creates an AppenderRef for each item then one could do Ralph > On Jan

Re: [DISCUSS] Support 'log4j.rootLogger=INFO,Console' configuration grammar in log4j2

I am curious if shall we adopt a more generic approach to extraction: ${sys:hadoop.root.logger} hadoop.root.logger.level hadoop.root.logger.appender On Mon, Jan 10, 2022 at 5:53 AM Ralph Goers wrote: > OK, I had a suspicion the reason for needing this was something li

Google OSS-Fuzz

I think fuzzing is a really promising practice we should integrate into our CI pipeline to figure out certain defects. Here is my elevator pitch: 1. Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid,