Re: [site] Jekyll proposal (in branch)
Hello, I made the Jekyll branch work with the staging environment: https://logging.staged.apache.org/ When you change something in the sources, it will be automatically deployed to Staging. We also have a "news section", aka blog: https://logging.staged.apache.org/blog/ To add or change a project, you made want to edit: https://github.com/apache/logging-site/blob/jekyll/_data/projects.yml You can edit it directly in Github UI if you prefer to try it out. It will take a few seconds to build and deploy. I want to move the Team members to a data file as well. If no objections, I'd like to move this to asf-site Kind regards, Christian On Tue, Oct 10, 2023, at 23:10, Christian Grobmeier wrote: > 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: [log4j] Improving log4j security
Hi Volkan, It's not just about exchanging data between systems - that is just one particular instance of a larger problem. If you use a pattern layout for _any_ reason, it is currently extremely inconvenient to configure securely. If you use a structured layout, again for any reason, it's still inconvenient to configure securely, though indeed less so than a pattern layout. My understanding is that not everyone can, will, or should always use a structured layout over a pattern layout. For entertainment, I have collected some layout statistics, which I include below. For the pattern layout case, I have prototyped improved encoders that can be used with log4j. The code has already been shared with you, though it will obviously need (lots of) discussion. I am happy to continue discussing the topic / working on the code with anyone who finds it worthwhile. Thanks, Vladimir Statistics: The dataset is certainly debatable, but it's the best one I have. Out of the top 1000 starred Java repositories on GitHub, 89 contain a file log4j2.xml with at least one element matching .*Layout. Out of these 89 repos, every single one defines at least one pattern layout. Only two repos out of 89 define a layout that is not a pattern layout: one repo a JSONLayout and one a StackdriverLayout. -Original Message- From: Volkan Yazıcı Sent: Wednesday, 11 October 2023 11:32 To: dev@logging.apache.org Subject: Re: [log4j] Improving log4j security Your use case sounds to me as follows: "I want to use `PatternLayout` for exchanging data between two systems and ... [it is insecure.]" (Please correct me if I am wrong.) My answer is: "Don't". `PatternLayout` is not designed to be machine-readable. If I am not mistaken, there is not even a standard format for stack traces. Consider ones generated from exceptions containing messages with newline characters. How are you gonna deal with parsing those? Or thread names, custom levels, custom markers, etc. with a newline? My point is, don't use `PatternLayout` for exchanging data between systems. For that purpose, we recommend using structured layouts, e.g., `JsonTemplateLayout`. ELK, Splunk, Datadog, NewRelic, etc. they all accept JSON. In conclusion, I recommend you to use JTL for publishing logs to other systems. If you have `PatternLayout` [encoder?] enhancements that we can incorporate in a backward-compatible way, please share.
Re: [log4j] Improving log4j security
This whole problem sounds as follows: - we don't escape because we don't think we should use a pattern layout like this - an attacker sends data to the log - the log sends data to a processing system - if this processing issue has a flaw, bad things might happen It does not sound like a widespread scenario, but a possible one. When I have learned one thing, it is we should not assume to know how a user might use a component. Even when we don't recommend this format for machine2machine, people still do it. I assume we could quickly make log4j safer by adding an encoder, as suggested by Vladimir, so my question is, why should we not do it? Kind regards, Christian On Thu, Oct 12, 2023, at 18:37, Klebanov, Vladimir wrote: > Hi Volkan, > > It's not just about exchanging data between systems - that is just one > particular instance of a larger problem. If you use a pattern layout > for _any_ reason, it is currently extremely inconvenient to configure > securely. If you use a structured layout, again for any reason, it's > still inconvenient to configure securely, though indeed less so than a > pattern layout. My understanding is that not everyone can, will, or > should always use a structured layout over a pattern layout. For > entertainment, I have collected some layout statistics, which I include > below. > > For the pattern layout case, I have prototyped improved encoders that > can be used with log4j. The code has already been shared with you, > though it will obviously need (lots of) discussion. I am happy to > continue discussing the topic / working on the code with anyone who > finds it worthwhile. > > Thanks, > Vladimir > > Statistics: The dataset is certainly debatable, but it's the best one I > have. Out of the top 1000 starred Java repositories on GitHub, 89 > contain a file log4j2.xml with at least one element matching .*Layout. > Out of these 89 repos, every single one defines at least one pattern > layout. Only two repos out of 89 define a layout that is not a pattern > layout: one repo a JSONLayout and one a StackdriverLayout. > > > -Original Message- > From: Volkan Yazıcı > Sent: Wednesday, 11 October 2023 11:32 > To: dev@logging.apache.org > Subject: Re: [log4j] Improving log4j security > > Your use case sounds to me as follows: "I want to use `PatternLayout` for > exchanging data between two systems and ... [it is insecure.]" (Please > correct me if I am wrong.) My answer is: "Don't". > > `PatternLayout` is not designed to be machine-readable. If I am not > mistaken, there is not even a standard format for stack traces. Consider > ones generated from exceptions containing messages with newline characters. > How are you gonna deal with parsing those? Or thread names, custom levels, > custom markers, etc. with a newline? My point is, don't use `PatternLayout` > for exchanging data between systems. For that purpose, we recommend using > structured layouts, e.g., `JsonTemplateLayout`. ELK, Splunk, Datadog, > NewRelic, etc. they all accept JSON. > > In conclusion, I recommend you to use JTL for publishing logs to other > systems. If you have `PatternLayout` [encoder?] enhancements that we can > incorporate in a backward-compatible way, please share.
[PR] Bump com.github.spotbugs:spotbugs-annotations from 4.7.3 to 4.8.0 [logging-log4j-jmx-gui]
dependabot[bot] opened a new pull request, #1: URL: https://github.com/apache/logging-log4j-jmx-gui/pull/1 Bumps [com.github.spotbugs:spotbugs-annotations](https://github.com/spotbugs/spotbugs) from 4.7.3 to 4.8.0. Release notes Sourced from https://github.com/spotbugs/spotbugs/releases";>com.github.spotbugs:spotbugs-annotations's releases. SpotBugs 4.8.0 CHANGELOG https://github.com/spotbugs/spotbugs/blob/4.8.0/CHANGELOG.md";>https://github.com/spotbugs/spotbugs/blob/4.8.0/CHANGELOG.md CHECKSUM file checksum (sha256) spotbugs-4.8.0-javadoc.jar 4cf102aa474ce8f3728e7513c51c0710024e4cd9d6b7c07672b5e3ec0e70a848 spotbugs-4.8.0-sources.jar d1e47bd320cae314a5c2b44e52152d8ca5f5f700713ba0f497dbed0a916540c2 spotbugs-4.8.0.tgz 15a97043faef7a371ae43137805ca83e89005c22253806b7c63a60a585e794c7 spotbugs-4.8.0.zip 768ac3bd6f5c49d1f12924ff3094ff281debc0ee218ae85ce5aae6f66ca0666a spotbugs-annotations-4.8.0-javadoc.jar d8ab5ebdaccff345d7167d2518fd74db72cf6b02b259d4f011689d48351c2b3e spotbugs-annotations-4.8.0-sources.jar b5d0110b70b9c44915f2c3375d1b700acb6d409152baf70030787d17a684469b spotbugs-annotations.jar f6644de2f0dfe4b614d3c9a35e9a8f1e1da1074892c8cad7a00bb08ce7bf4eff spotbugs-ant-4.8.0-javadoc.jar 1285df769e00a9fbeb6edceec856b361fb7f5f79762d3f2a768ce71d31cf7bb5 spotbugs-ant-4.8.0-sources.jar 9f1431331363f45ceb9b91c0e5246eab574fbff81c56eff0e385f572d346de61 spotbugs-ant.jar a798346790437cdc18217379fa54a7e6b044ba2070891ebe01faee28af79af6c spotbugs.jar 1ce2fa740d7f07b802881babb27dd26f74861ff2ac938718779ce8a7cb5fe14c test-harness-4.8.0-javadoc.jar 3191c34729c1dedb4964dfc8a0cd5917457e6271291688ff6d5fc3b9c96868f6 test-harness-4.8.0-sources.jar 633ae795c1889fa59f1faad8ea8f1f5b39155029f4f75b51557085097570feb6 test-harness-4.8.0.jar 23f414f9988a3d44dded88ad2d827e95699dc6bb8d6e06a2b0920db2cac442b9 test-harness-core-4.8.0-javadoc.jar 33c6e66ac7a08344afe48aa5ba1d5be22ec79065e50b235530c02d46818a7018 test-harness-core-4.8.0-sources.jar f5db3e4ebf3f90c9bbf4815824c9d94f93fb740c9610b6f70a64bf7896a4e082 test-harness-core-4.8.0.jar 5bd0e9b18f0ec45c27ee3ec882cb6db86ed42a6b884f091468496de3281dc242 test-harness-jupiter-4.8.0-javadoc.jar 5ff08084863aa6f6579e97e83d9c0ba2b7620663d0f0b0a777f09d99ba06dc8c test-harness-jupiter-4.8.0-sources.jar 0aefbc5c8bd406e5dc0b1d59bc3afc6889c02010d486b22242f4f19a1a935800 test-harness-jupiter-4.8.0.jar d2ed802cc81dca3cf8c393fda7f77f02b01c0c1a8ffce7ec57da53aff27a1485 Changelog Sourced from https://github.com/spotbugs/spotbugs/blob/master/CHANGELOG.md";>com.github.spotbugs:spotbugs-annotations's changelog. 4.8.0 - 2023-10-11 Changed Bump up Apache Commons BCEL to the version 6.6.1 (https://redirect.github.com/spotbugs/spotbugs/pull/2223";>#2223) Bump up slf4j-api to 2.0.3 (https://redirect.github.com/spotbugs/spotbugs/pull/2220";>#2220) Bump up gson to 2.10 (https://redirect.github.com/spotbugs/spotbugs/pull/2235";>#2235) Allowed for large command line through writing arguments to file (UnionResults/UnionBugs2) Use com.github.stephenc.jcip for jcip-annotations fixing https://redirect.github.com/spotbugs/spotbugs/issues/887";>#887 Fixed Fixed missing classes not in report if using IErrorLogger.reportMissingClass(ClassDescriptor) (https://redirect.github.com/spotbugs/spotbugs/issues/219";>#219) Stop exposing junit-bom to consumers (https://redirect.github.com/spotbugs/spotbugs/pull/2255";>#2255) Fixed AbstractBugReporter emits wrong non-sensical debug output during filtering (https://redirect.github.com/spotbugs/spotbugs/issues/184";>#184) Added support for jakarta namespace (https://redirect.github.com/spotbugs/spotbugs/pull/2289";>#2289) Report a low priority bug for an unread field in reflective classes (https://redirect.github.com/spotbugs/spotbugs/issues/2325";>#2325) Fixed "Unhandled event loop exception" opening Bug Filter Configuration dialog in Eclipse (https://redirect.github.com/spotbugs/spotbugs/issues/2327";>#2327) Fixed detector RandomOnceSubDetector to not report when doubles, ints, or longs are called on a new Random or SecureRandom (https://redirect.github.com/spotbugs/spotbugs/issues/2325";>#2370) Fixed detector TestASM throwing error during analysis, because it doesn't note that it reports bugs. Eclipse annotation classpath initializer is hard-coded to jsr305 version 3.0.1, fix to 3.0.2 per https://redirect.github.com/spotbugs/spotbugs/issues/2470";>#2470 Fixed annotation on generic or array incorrectly considered for the nullability of a method parameter or return type (https://redirect.github.com/spotbugs/spotbugs/issues/2502";>#2502) Added
Re: [log4j] Improving log4j security
Hi Christian, On Thu, 12 Oct 2023 at 20:11, Christian Grobmeier wrote: > I assume we could quickly make log4j safer by adding an encoder, as suggested > by Vladimir, so my question is, why should we not do it? Yes, we can easily add an `outputFormat` attribute to the pattern layout that accepts the same values as the `%enc` pattern. This way users can easily apply JSON or XML encoding to their messages. However we should consider properly documenting PatternLayout: there should be a warning reminding users that while it is technically possible to generate a proper JSON or XML using this layout it is not the suggested way. Piotr
Re: [log4j] Improving log4j security
On Thu, Oct 12, 2023, at 20:44, Piotr P. Karwasz wrote: > However we should consider properly documenting PatternLayout: there > should be a warning reminding users that while it is technically > possible to generate a proper JSON or XML using this layout it is not > the suggested way. No objections to letting people know how it is supposed to work :)
