Re: Status of log4j-audit
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 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 >>> 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 >>
[site] Jekyll proposal (in branch)
Hello, Based on recent comments, I made a branch for using Jekyll on the leading site. It's a branch, we can discard it. The migration took me 1.5h, excluding this e-mail - not much wasted. https://github.com/apache/logging-site/tree/jekyll This is not yet auto-deployed, but if nobody opposes it, I will move on, merge, and autodeploy. Here is some info: Jekyll supports data files like this: https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml In the future, one could modify those data files directly from GitHub UI to update a status or a team member. It would be autodeployed then. The code for the output is also simple: https://github.com/apache/logging-site/blob/jekyll/index.html The amount of HTML has decreased. In addition, I was able to use Flexbox, which is built-in to browsers (no more slow Bootstrap in this case) We also can make use of SCSS now, which can use advanced CSS (in this case only nesting): https://github.com/apache/logging-site/blob/jekyll/css/site.scss#L44 The current team list could be moved to a data file, too, but I left it as adoc to showcase that this Jekyll page can work with adoc as well: https://github.com/apache/logging-site/blob/jekyll/team-list.adoc If you want to work with Jekyll, you can run the scripts: ./run-docker-build.sh (only one time; Docker needs to be installed) ./run-jekyll.sh (when you want to work) This way, you can build locally and check. However, you don't need to do this to update tiny things quickly. Please let me know if you want to object; otherwise, I would love to move this forward. If we, at some later point in time, move on to something like Antora, I will gladly help to migrate; however, since we are using adoc for this website as well, it should be straightforward. As soon as I have a go for this, I will prepare a blog section announcing the latest releases and preparing everything for some announcements we had in mind on the PMC list. Kind regards, Christian
Re: Status of log4j-audit
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 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 >> 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 >
Re: Status of log4j-audit
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 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
Re: Status of log4j-audit
I think it would be nice to do a release just to update dependencies. Gary On Tue, Oct 10, 2023, 2:33 PM Christian Grobmeier 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 >
Status of log4j-audit
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
Re: [VOTE] Release Apache Log4j Scala 13.0.0
+1 I also agree that the Scala 3 reproducible build issue is minor. > On Oct 10, 2023, at 6:21 AM, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Scala 13.0.0. > > Website: https://logging.staged.apache.org/log4j/scala > GitHub: https://github.com/apache/logging-log4j-scala > Commit: 980f4ed0ba53f93d1514df65ddafb6f97396a975 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1200 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. > > === Reproducibility > > The `log4j-api-scala_3.jar` artifact targeting Scala 3 in this release > is not reproducible due to a bug in the Scala 3 compiler[1]. (The > other 4 artifacts are reproducible!) Though I don't find this a > release blocker since we can verify that the difference breaking the > reproducibility is just a member ordering problem, which doesn't have > any practical effect from a user's point of view. > > [1] https://github.com/lampepfl/dotty/issues/18248 > > What about CI checks? > > Note that CI-based reproducibility checks pass, since the issue > appears to be only observable when sources are built on hosts with > different specs. > > How can I check the reproducibility myself? > > export > NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1200 > ./mvnw verify artifact:compare -Dreference.repo=$NEXUS_REPO > > How can I view the difference myself? > > ./mvnw package > mkdir t && cd $_ > wget > https://repository.apache.org/content/repositories/orgapachelogging-1200/org/apache/logging/log4j/log4j-api-scala_3/13.0.0/log4j-api-scala_3-13.0.0.jar > unzip log4j-api-scala_3-13.0.0.jar -d reference > unzip ../log4j-api-scala_3/target/log4j-api-scala_3-13.0.0.jar -d local > diff -r reference local > # `diff` will point out that only `LoggingContext$.class` doesn't match > javap 'reference/org/apache/logging/log4j/scala/LoggingContext$.class' >> reference.LoggingContext > javap 'local/org/apache/logging/log4j/scala/LoggingContext$.class' > > local.LoggingContext > diff -u reference.LoggingContext local.LoggingContext > > What is the difference? > > Decompiling and comparing `LoggingContext$.class` files produce the > following output: > > --- reference.LoggingContext 2023-10-10 12:58:35.188544183 +0200 > +++ local.LoggingContext 2023-10-10 12:58:41.152551071 +0200 > @@ -114,30 +114,30 @@ > public scala.collection.LazyZip2 lazyZip(scala.collection.Iterable); > public scala.collection.IterableFactory iterableFactory(); > public scala.Function1 compose(scala.Function1); > - public double apply$mcDI$sp(int); > - public double apply$mcDJ$sp(long); > - public double apply$mcDF$sp(float); > - public double apply$mcDD$sp(double); > + public int apply$mcII$sp(int); > + public int apply$mcIJ$sp(long); > + public int apply$mcIF$sp(float); > + public int apply$mcID$sp(double); > public boolean apply$mcZI$sp(int); > public boolean apply$mcZJ$sp(long); > public boolean apply$mcZF$sp(float); > public boolean apply$mcZD$sp(double); > - public long apply$mcJI$sp(int); > - public long apply$mcJJ$sp(long); > - public long apply$mcJF$sp(float); > - public long apply$mcJD$sp(double); > - public void apply$mcVI$sp(int); > - public void apply$mcVJ$sp(long); > - public void apply$mcVF$sp(float); > - public void apply$mcVD$sp(double); > public float apply$mcFI$sp(int); > public float apply$mcFJ$sp(long); > public float apply$mcFF$sp(float); > public float apply$mcFD$sp(double); > - public int apply$mcII$sp(int); > - public int apply$mcIJ$sp(long); > - public int apply$mcIF$sp(float); > - public int apply$mcID$sp(double); > + public void apply$mcVI$sp(int); > + public void apply$mcVJ$sp(long); > + public void apply$mcVF$sp(float); > + public void apply$mcVD$sp(double); > + public double apply$mcDI$sp(int); > + public double apply$mcDJ$sp(long); > + public double apply$mcDF$sp(float); > + public double apply$mcDD$sp(double); > + public long apply$mcJI$sp(int); > + public long apply$mcJJ$sp(long); > + public long apply$mcJF$sp(float); > + public long apply$mcJD$sp(double); > public scala.Option unapply(java.lang.Object); > public scala.PartialFunction elementWise(); > public scala.PartialFunction orElse(scala.PartialFunction); > > Why is it a simple ordering problem? > > Since `grep -E 'public (.+) apply\$' | sort` executed against both > `reference.LoggingContext` and `local.LoggingContext`
Re: Breaking changes in Log4j API 3.x
Use PropertyEnvironment; it’s the public API. The only methods not exposed by it are internal ones like reload which are used by some tests. > On Oct 9, 2023, at 6:37 PM, Ralph Goers wrote: > > > >> On Oct 9, 2023, at 2:14 PM, Piotr P. Karwasz wrote: >> >> On Mon, 9 Oct 2023 at 20:57, Ralph Goers wrote: >>> We cannot put users in a position where they cannot upgrade until all their >>> dependencies do. >> >> I agree, at work I still had a lot of libraries that depended on >> Commons Lang 2, although >> >>> Note that Spring Boot builds with Log4j 2.x. It needs access to >>> PerformanceSensitive, PropertiesUtil, and PropertySource. >> >> I would really prefer not to export `PropertiesUtil`, but at least we >> can migrate many other internal classes. > > Unfortunately, the way PropertiesUtil was implemented makes it impossible to > make private. Lots of things need access to properties. > > Ralph >
RE: [log4j] Improving log4j security
Hi Volkan, Let me try to clarify. The goal/usecase is not to log as an HTML document. We are assuming a typical text-based log here. Yet, in practice, the logs will be processed by a variety of systems, including web-based ones, which may have various vulnerabilities. These vulnerabilities can be exploited by attackers if they can use the log-producing application to inject various strings into the log. (At this point, I would like to refer to the context paragraph of my previous message.) Here is an example scenario spelled out. An application uses log4j to produce a text log, while logging the username supplied by the user in every login attempt. The log is ingested into Splunk (or ELK), as it often is. An attacker can try to login with the username
Re: [VOTE] Release Apache Log4j Scala 13.0.0
Hi Volkan, On Tue, 10 Oct 2023 at 13:24, Volkan Yazıcı wrote: > > This is a vote to release the Apache Log4j Scala 13.0.0. > > Website: https://logging.staged.apache.org/log4j/scala > GitHub: https://github.com/apache/logging-log4j-scala > Commit: 980f4ed0ba53f93d1514df65ddafb6f97396a975 > Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala > Nexus: > https://repository.apache.org/content/repositories/orgapachelogging-1200 > Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 > > Please download, test, and cast your votes on this mailing list. > > [ ] +1, release the artifacts > [ ] -1, don't release, because... > > This vote is open for 72 hours and will pass unless getting a > net negative vote count. All votes are welcome and we encourage > everyone to test the release, but only the Logging Services PMC > votes are officially counted. At least 3 +1 votes and more > positive than negative votes are required. I checked: * that the artifacts for Scala 2.x are reproducible from both the Git tag and source archive, * that in Scala 3.x the irreproducibility problem is restricted to the bug Arnout submitted: https://github.com/lampepfl/dotty/issues/17330, * the web site looks nice, although I am not a big fan of redirections via http-equiv="refresh", There is a minor problem with the OSGi headers: the `Bundle-Description` header is inherited from `logging-parent`: Bundle-Description Parent project internally used in Maven-based projects of the Apache Logging Services I don't see this as a blocker, so +1 and great job. Piotr
Re: Log4j Audit
Sure Ralph > On Oct 10, 2023, at 2:05 AM, Piotr P. Karwasz wrote: > > Hi all, > > Since Log4j Audit will not be archived, could someone update its > dependencies? Dependabot has lots of security alerts about it: > > https://github.com/apache/logging-log4j-audit/security/dependabot > > Piotr
[VOTE] Release Apache Log4j Scala 13.0.0
This is a vote to release the Apache Log4j Scala 13.0.0. Website: https://logging.staged.apache.org/log4j/scala GitHub: https://github.com/apache/logging-log4j-scala Commit: 980f4ed0ba53f93d1514df65ddafb6f97396a975 Distribution: https://dist.apache.org/repos/dist/dev/logging/log4j-scala Nexus: https://repository.apache.org/content/repositories/orgapachelogging-1200 Signing key: 0x077e8893a6dcc33dd4a4d5b256e73ba9a0b592d0 Please download, test, and cast your votes on this mailing list. [ ] +1, release the artifacts [ ] -1, don't release, because... This vote is open for 72 hours and will pass unless getting a net negative vote count. All votes are welcome and we encourage everyone to test the release, but only the Logging Services PMC votes are officially counted. At least 3 +1 votes and more positive than negative votes are required. === Reproducibility The `log4j-api-scala_3.jar` artifact targeting Scala 3 in this release is not reproducible due to a bug in the Scala 3 compiler[1]. (The other 4 artifacts are reproducible!) Though I don't find this a release blocker since we can verify that the difference breaking the reproducibility is just a member ordering problem, which doesn't have any practical effect from a user's point of view. [1] https://github.com/lampepfl/dotty/issues/18248 What about CI checks? Note that CI-based reproducibility checks pass, since the issue appears to be only observable when sources are built on hosts with different specs. How can I check the reproducibility myself? export NEXUS_REPO=https://repository.apache.org/content/repositories/orgapachelogging-1200 ./mvnw verify artifact:compare -Dreference.repo=$NEXUS_REPO How can I view the difference myself? ./mvnw package mkdir t && cd $_ wget https://repository.apache.org/content/repositories/orgapachelogging-1200/org/apache/logging/log4j/log4j-api-scala_3/13.0.0/log4j-api-scala_3-13.0.0.jar unzip log4j-api-scala_3-13.0.0.jar -d reference unzip ../log4j-api-scala_3/target/log4j-api-scala_3-13.0.0.jar -d local diff -r reference local # `diff` will point out that only `LoggingContext$.class` doesn't match javap 'reference/org/apache/logging/log4j/scala/LoggingContext$.class' > reference.LoggingContext javap 'local/org/apache/logging/log4j/scala/LoggingContext$.class' > local.LoggingContext diff -u reference.LoggingContext local.LoggingContext What is the difference? Decompiling and comparing `LoggingContext$.class` files produce the following output: --- reference.LoggingContext 2023-10-10 12:58:35.188544183 +0200 +++ local.LoggingContext 2023-10-10 12:58:41.152551071 +0200 @@ -114,30 +114,30 @@ public scala.collection.LazyZip2 lazyZip(scala.collection.Iterable); public scala.collection.IterableFactory iterableFactory(); public scala.Function1 compose(scala.Function1); - public double apply$mcDI$sp(int); - public double apply$mcDJ$sp(long); - public double apply$mcDF$sp(float); - public double apply$mcDD$sp(double); + public int apply$mcII$sp(int); + public int apply$mcIJ$sp(long); + public int apply$mcIF$sp(float); + public int apply$mcID$sp(double); public boolean apply$mcZI$sp(int); public boolean apply$mcZJ$sp(long); public boolean apply$mcZF$sp(float); public boolean apply$mcZD$sp(double); - public long apply$mcJI$sp(int); - public long apply$mcJJ$sp(long); - public long apply$mcJF$sp(float); - public long apply$mcJD$sp(double); - public void apply$mcVI$sp(int); - public void apply$mcVJ$sp(long); - public void apply$mcVF$sp(float); - public void apply$mcVD$sp(double); public float apply$mcFI$sp(int); public float apply$mcFJ$sp(long); public float apply$mcFF$sp(float); public float apply$mcFD$sp(double); - public int apply$mcII$sp(int); - public int apply$mcIJ$sp(long); - public int apply$mcIF$sp(float); - public int apply$mcID$sp(double); + public void apply$mcVI$sp(int); + public void apply$mcVJ$sp(long); + public void apply$mcVF$sp(float); + public void apply$mcVD$sp(double); + public double apply$mcDI$sp(int); + public double apply$mcDJ$sp(long); + public double apply$mcDF$sp(float); + public double apply$mcDD$sp(double); + public long apply$mcJI$sp(int); + public long apply$mcJJ$sp(long); + public long apply$mcJF$sp(float); + public long apply$mcJD$sp(double); public scala.Option unapply(java.lang.Object); public scala.PartialFunction elementWise(); public scala.PartialFunction orElse(scala.PartialFunction); Why is it a simple ordering problem? Since `grep -E 'public (.+) apply\$' | sort` executed against both `reference.LoggingContext` and `local.LoggingContext` produce the same output. === Release Notes The highlights of this major release are Scala 3 support, JPMS descriptors, and the switch to semantic versioning[2]. [2] https://semver.org Note that this release is still binary backward compatible with the earlier release `12.0`. Though we needed to bump the major version number for the semantic
Log4j Audit
Hi all, Since Log4j Audit will not be archived, could someone update its dependencies? Dependabot has lots of security alerts about it: https://github.com/apache/logging-log4j-audit/security/dependabot Piotr
