As long as we can get those security issues released, I am fine.
Personally I am fine with helping with the editor, if it stays as web app (I 
can do react and such).
If it's JavaFX - I am lost. I have hard time helping with Swing in Chainsaw.

Since you mentioned its importance, we should work on a release very soon. It 
is really hard to justify the presence of those security issues, even when I 
understood from Matt that users need to chose their versions themselves.

Still, I am not perfectly clear of what you will do with it and what the 
"additional audit apis" actually are. I have a feeling though. 

On Tue, Oct 10, 2023, at 22:53, Ralph Goers wrote:
> Yes, I can update the dependencies and do a release.
>
> The primary issue with the project as it stands is the Catalog Editor 
> UI. It is really stupid. It uses Spring Boot for the UI but it is meant 
> to run locally. It was suggested I switch the UI to JavaFX but I have 
> never had the chance.
>
> FWWI - Log4j-Audit is the entire reason I created Log4j2. It cannot 
> work with SLF4J/Logback.
>
> Ralph
>
>
>> On Oct 10, 2023, at 1:48 PM, Matt Sicker <m...@musigma.org> wrote:
>> 
>> Log4j Audit has multiple components:
>> 
>> * Audit API for extending log4j-api with some additional audit logging APIs
>> * Tool for managing your audit event schemata and such (the web app thing)
>> * Tool for generating structured log classes from the event schemata
>> 
>> Thus, in typical use, you can (and should) specify what version of 
>> log4j-core you’re using for your application. As for maintenance, the web UI 
>> could use an overhaul (though it would likely involve a rewrite into 
>> something more popular like React), but the overall library is fairly 
>> compact. I do have an outstanding Jira issue for Log4j to work on a more 
>> fluent API for structured logging, and that sort of feature can be informed 
>> or inspired by log4j-audit.
>> 
>> As for the log4j-server question, I’d expect that if we adopt Flume into the 
>> PMC, then Flume would supersede the server examples since we’d have 
>> something far more mature and production-ready for such a use case.
>> 
>>> On Oct 10, 2023, at 1:33 PM, Christian Grobmeier <grobme...@apache.org> 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> We have been talking about log4j-audit (same thread as with log4j-server).
>>> 
>>> I have checked today after seeing Piotr's message, and even after reading 
>>> the readme, I am still trying to figure out the purpose of this product. 
>>> That aside, I am concerned the last change was four years ago. -audit is 
>>> depending to Log4j 2.10, which is affected by log4shell.
>>> 
>>> I checked on the releases, and I see only RCs here:
>>> https://github.com/apache/logging-log4j-audit/tags
>>> But two releases here:
>>> https://logging.apache.org/log4j-audit/latest/download.html
>>> 
>>> What message are we sending?
>>> 
>>> As I understand it we are currently promoting software that contains 
>>> log4shell without any word of warning or any development plan on the 
>>> horizon.
>>> 
>>> Do we have any development cycles left to fix at least the security issues, 
>>> with the Flume project probably merging into this project?
>>> 
>>> I am not asking for the "will power", but the "real power": if it is not 
>>> realistic to maintain this project, we should add warning labels, consider 
>>> EOL, and/or actively search for contributors.
>>> 
>>> I am willing to support a bit, but only if I understand the use of -audit :)
>>> 
>>> Kind regards,
>>> Christian
>>

Reply via email to