tersesystems / terse-logback Goto Github PK

Describe the bug
When using censors, if multiple are applied to net.logstash.logback.encoder.LogstashEncoder using com.tersesystems.logback.censor.CensoringJsonGeneratorDecorator, the last censor-ref "wins" and the others are ignored.

To Reproduce

• I created a fairly minimal project reproducing the issue
• In particular, the way this configuration interacts with this code is the issue

Expected behavior
I expected both censors to be applied to logs, but only the last censor listed in the configuration is applied.

Screenshots
(Not a screenshot, but here's the output I'm seeing)

13:51:37,844 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
13:51:37,845 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/Users/tim.walter/dev/terse-logback/java/target/classes/logback.xml]
13:51:37,887 |-INFO in ch.qos.logback.core.joran.action.NewRuleAction - About to add new Joran parsing rule [*/censor,com.tersesystems.logback.censor.CensorAction].
13:51:37,887 |-INFO in ch.qos.logback.core.joran.action.NewRuleAction - About to add new Joran parsing rule [*/censor-ref,com.tersesystems.logback.censor.CensorRefAction].
13:51:37,888 |-INFO in ch.qos.logback.core.joran.action.ConversionRuleAction - registering conversion word censor with class [com.tersesystems.logback.censor.CensorConverter]
13:51:37,888 |-INFO in com.tersesystems.logback.censor.CensorAction - About to instantiate censor of type [com.tersesystems.logback.censor.RegexCensor]
13:51:37,889 |-INFO in com.tersesystems.logback.censor.CensorAction - Naming censor as [hunter2]
13:51:37,892 |-INFO in com.tersesystems.logback.censor.CensorAction - About to instantiate censor of type [com.tersesystems.logback.censor.RegexCensor]
13:51:37,892 |-INFO in com.tersesystems.logback.censor.CensorAction - Naming censor as [social-security-number]
13:51:37,893 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
13:51:37,895 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
13:51:37,912 |-INFO in com.tersesystems.logback.censor.CensorRefAction - Attaching censor named [hunter2] to com.tersesystems.logback.censor.CensoringJsonGeneratorDecorator@35b3557eat 27
13:51:37,912 |-INFO in com.tersesystems.logback.censor.CensorRefAction - Attaching censor named [social-security-number] to com.tersesystems.logback.censor.CensoringJsonGeneratorDecorator@35b3557eat 28
13:51:38,020 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
13:51:38,020 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
13:51:38,020 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
13:51:38,021 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@1188cc16 - Registering current configuration as safe fallback point
{"@timestamp":"2022-09-22T13:51:38.022-04:00","@version":"1","message":"hunter2","logger_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main","thread_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main.main()","level":"INFO","level_value":20000}
{"@timestamp":"2022-09-22T13:51:38.03-04:00","@version":"1","message":"[CENSORED: Social Security Number: 000-11-XXX2]","logger_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main","thread_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main.main()","level":"INFO","level_value":20000}
{"@timestamp":"2022-09-22T13:51:38.041-04:00","@version":"1","message":"SocialSecurityNumber[socialSecurityNumber[CENSORED: Social Security Number: 000-11-XXX2]","logger_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main","thread_name":"io.github.dutchmahoney.terselogbackcensorsexample.Main.main()","level":"INFO","level_value":20000}

Desktop (please complete the following information):

• OS: MacOS
• Version: 12.6

Additional context
Nothing more to add but "thanks!"

Hi, @sullis , @eudes , I'd like to report a vulnerability issue in com.tersesystems.logback:logback-compress-encoder:1.0.2.

Issue Description

I noticed that com.tersesystems.logback:logback-compress-encoder:1.0.2 directly depends on com.github.luben:zstd-jni:v1.4.0-1 in the pom. However, as shown in the following dependency graph. However, com.github.luben:zstd-jni:v1.4.0-1 sufferes from the vulnerability which the C library zstd(version:1.4.0) exposed: CVE-2021-24031.

Dependency Graph between Java and Shared Libraries

Suggested Vulnerability Patch Versions

com.github.luben:zstd-jni:v1.4.9-1 (>=v1.4.9-1) has upgraded this vulnerable C library zstd to the patch version 1.4.9.

Java build tools cannot report vulnerable C libraries, which may induce potential security issues to many downstream Java projects. Could you please upgrade this vulnerable dependency?

Thanks for your help~
Best regards,
Helen Parr

Describe the bug
During today's scheduled bintray brown out our builds started failing as the following maven coordinates could not resolve:

com.tersesystems.logback:logback-structured-config:0.16.1

The brownouts are a precursor to the eventual shutdown of bintray and jcenter. The fix is to start publishing to maven central.

Create a manual / website from 'gh-pages' and asciidoc.

• Convert from Markdown to Asciidoc with pandoc
• Add code snippets directly from page with https://github.com/asciidoctor/asciidoctor-extensions-lab/

Tracked with #17

Currently in the JDK, an failed assert will throw an AssertionError. Because the default uncaught exception handler doesn't have any kind of handling of AssertionError, this means that there's no logging or tracking of a failed assert past the stacktrace.

On top of that, assertions are only enabled if you have -ea set in the Java runtime.

https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.UncaughtExceptionHandler.html

https://docs.oracle.com/javase/11/docs/api/java/lang/AssertionError.html

http://www.javapractices.com/topic/TopicAction.do?Id=229

On one hand, this makes assertions a pain in a live environment. On the other hand, enabling assertions in a test suite could be a great way to add extra conditions and terminate early without binding junit code directly into executable code -- a junit assert can happen in a test, but you can stick assert anywhere in the codebase.

Assertion handling in particular is far more interesting than the documentation makes it out to be.

https://docs.oracle.com/javase/7/docs/technotes/guides/language/assert.html#design-faq-general

For example, you can turn on assertions dynamically for a package or a single class, using the classloader! Sadly only seems to apply when the class is first loaded, so you can't change it after that (or can you?)

https://docs.oracle.com/javase/9/docs/api/java/lang/ClassLoader.html#setPackageAssertionStatus-java.lang.String-boolean-

At the very least, assertions should trigger a dump of diagnostic logging statements associated with the thread, i.e. from Blacklite so that the operations leading up to the assertion are visible.

If there are errors or warnings, the appender should be able to up the logging level for the logger (or package) to DEBUG, for example.

We have seen an open vulnerability using OWASP checks in logback because of an audio module in logback:
https://nvd.nist.gov/vuln/detail/CVE-2018-14948

The dependency: https://github.com/Trilarion/java-vorbis-support

However, I could not find any documentation on why logback needs this audio module besides of this: https://tersesystems.com/blog/2019/05/18/application-logging-in-java-part-4/

Unfortunately, this tutorial doesn't explain the use case.
Is it really necessary for a logging library to have a dependency to audio libraries?

In the situation where there's an e.printStackTrace() we should be able to use bytebuddy to rewrite this to something more like:

Logger logger = LoggerFactory.getLogger(this.getClass());
logger.error(e.getMessage(), e);

This should be able to apply even when you didn't write the code in question.

https://stackoverflow.com/questions/67404010/how-can-i-make-a-log-for-exceptions-using-jdbc/67404400#67404400

Is your feature request related to a problem? Please describe.
We have been using structured logging directly to console for quite some time for our kubernetes JVMs. However it seems the current implementation of this library only supports JSON to file.

Describe the solution you'd like
Support JSON output to console as well, for deployed (production) workloads. For local development, we like plain old one-line logging. Unit testing against resulting JSON output should still work in development.

Describe alternatives you've considered
None

Additional context
Our agent requires "one linebreak per log statement".

Fix the TypesafeConfigAction and configuration so it has

levels {

}

local {

}

context {

}

and then doesn't need explicit scoping