December 2018 - slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 25 Dec '18

25 Dec '18

[ https://jira.qos.ch/browse/SLF4J-451?page=com.atlassian.jira.plugin.system.… ] Igor Stepanov commented on SLF4J-451: ------------------------------------- Same is reproducible for {{1.7.25}}. It's detected by {{org.owasp:dependency-check-maven:check}} maven command. We get next output after the check: {code} slf4j-api-1.7.25.jar (org.slf4j:slf4j-api:1.7.25, cpe:/a:slf4j:slf4j:1.7.25) : CVE-2018-8088 {code} > org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: SLF4J-451 > URL: https://jira.qos.ch/browse/SLF4J-451 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Affects Versions: 1.8.0-beta2 > Environment: Linux > Reporter: Narayan > Assignee: SLF4J developers list > Labels: logging > > More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 24 Dec '18

24 Dec '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Roded commented on SLF4J-371: ----------------------------- Any update on this issue? Kind of a pain that SLF4J misses what JUL has since Java 8. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 23 Dec '18

23 Dec '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-192: ----------------------------------------- You have a backend dependency anyway. At least you have a logback.xml (or whatever configuration file you use). Whatever has this file - main program, application container, whatever - is also the right place to close logging resources. No facade is perfect - you need to set it up and tear it down somewhere. The point of a facade is not to remove all traces, it is to concentrate them in a single place where it is easy to control. > Need ability to shutdown loggers and flush appenders > ---------------------------------------------------- > > Key: SLF4J-192 > URL: https://jira.qos.ch/browse/SLF4J-192 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.6.x > Environment: Operating System: All > Platform: All > Reporter: Michael Schall > Assignee: SLF4J developers list > > There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. > Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? > For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); > For logback it would call - loggerContext.stop() > Other back ends - ??? > This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. > Discussion about this is happening on the user list at - > http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-192) Need ability to shutdown loggers and flush appenders
by QOS.CH (JIRA) 23 Dec '18

23 Dec '18

[ https://jira.qos.ch/browse/SLF4J-192?page=com.atlassian.jira.plugin.system.… ] Andrea Santi commented on SLF4J-192: ------------------------------------ 8 years? Really? After 8 years we are still debating about this? There are some resources that need to be cleaned when the application close. There are some appenders that need to shutdown resources gracefully when an application is closed. E.g. the logfaces appender creates background threads to send logs to an external log monitoring system and without a proper shutdown hook in SLF4J api they are destined to stay there in background and create a huge leak. Since I'm using log4j 2 as the underlying logging library today I'm forced to do the following *LogManager.shutdown();* But this is so wrong! It entirely blows up the idea of the *FACADE*. If we need to directly call a method of the *REAL* implementation of the logging library then this is not a FACADE anymore. I totally agree with Alexander and Sean. " *If I am building a code dependency on the underlying logger, why even use SLF4J?* What can be done to make things progress? Open another ticket (version 1.6 is no longer "actual")? Any feedback woudl be really appreciated. > Need ability to shutdown loggers and flush appenders > ---------------------------------------------------- > > Key: SLF4J-192 > URL: https://jira.qos.ch/browse/SLF4J-192 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.6.x > Environment: Operating System: All > Platform: All > Reporter: Michael Schall > Assignee: SLF4J developers list > > There needs to be a way to shutdown logging and flush async appenders so when a process is closing, all log events are written before the process is closed. > Should ILoggerFactory have a shutdown or stop method? It could shutdown whatever logging back end I'm using? > For log4j it would call - org.apache.log4j.LogManager.getLoggerRepository().shutdown(); > For logback it would call - loggerContext.stop() > Other back ends - ??? > This is required to allow me to not reference logging back ends explicitly in my code to shutdown successfully without losing events. > Discussion about this is happening on the user list at - > http://www.qos.ch/pipermail/logback-user/2010-September/001816.html -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-451) org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data.
by QOS.CH (JIRA) 19 Dec '18

19 Dec '18

Narayan created SLF4J-451: ----------------------------- Summary: org.slf4j.ext.EventData in the slf4j-ext module in QOS.CH SLF4J before 1.8.0-beta2 allows remote attackers to bypass intended access restrictions via crafted data. Key: SLF4J-451 URL: https://jira.qos.ch/browse/SLF4J-451 Project: SLF4J Issue Type: Bug Components: slf4j-ext Affects Versions: 1.8.0-beta2 Environment: Linux Reporter: Narayan Assignee: SLF4J developers list More details is available in [https://nvd.nist.gov/vuln/detail/CVE-2018-8088|https://nvd.nist.gov/vuln/de…] -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-450) Allow binding to be explicitly specified
by QOS.CH (JIRA) 17 Dec '18

17 Dec '18

Chris Lee created SLF4J-450: ------------------------------- Summary: Allow binding to be explicitly specified Key: SLF4J-450 URL: https://jira.qos.ch/browse/SLF4J-450 Project: SLF4J Issue Type: Improvement Components: Core API Affects Versions: 1.8.0-beta2 Reporter: Chris Lee Assignee: SLF4J developers list Currently SLF4J (1.8+) uses ServiceLoader to find bindings; as an improvement for performance sensitive (or otherwise restricted) environments allow the binding to be explicitly specified. For example: {code:java} -Dslf4j.binding=ch.qos.logback.classic.spi.LogbackServiceProvider{code} In the event this property isn't specified then logic could fall-through to existing ServiceLoader behaviour. Examples of where this would be valuable: 1) Cloud functions sensitive to cold-start times (e.g. AWS Lambda). Avoiding scanning the classpath reduces startup time (and hence request processing time for requests incurring a cold start). This is the my use case. 2) Class-loader challenged environments where ServiceLoader may not behave as expected; specifying the precise class to load may allow for workarounds. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Status of EventData removal defect
by Michael Ahern 14 Dec '18

14 Dec '18

1 0

JDK 12 enters Rampdown Phase One
by Rory O'Donnell 14 Dec '18

14 Dec '18

Hi Ceki, *JDK 12 Early Access build **is now available **at : - jdk.java.net/12/* * Per the JDK 12 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. o We’ve forked the main-line source repository, jdk/jdk, to the JDK 12 stabilization repository. Changes since the last availability email * JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*. * JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved to *Targeted*. * JEP 344: Abortable Mixed Collections for G1 <http://openjdk.java.net/jeps/344> moved to *Targeted*. * JEP 346: Promptly Return Unused Committed Memory from G1 <http://openjdk.java.net/jeps/346> to *Targeted*. * JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326> (Preview) *Proposed to drop from JDK 12* o link to proposal on jdk-dev <https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html> Bug fixes reported by Open Source Projects : o JDK-8211051 - fixed in b22 - reported by JUnit5 o JDK-8211422 - fixed in b23 - reported by Apache Batik The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been updated with the following target: * With the 2019-04-16 CPU, o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7 o Distrust TLS server certificates anchored by Symantec Root CAs. Oracle Java SE 8 Release Updates [3] * Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license. Rgds, Rory [1] http://openjdk.java.net/projects/jdk/12/#Schedule [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html [3] https://java.com/en/download/release_notice.jsp -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

jpms update...
by John Patrick 09 Dec '18

09 Dec '18

hello calling any slf4j developers/commiters... looking at jira and github i can't see any activity since March 2018 when 1.8.0-beta2 was released... 1) any update on if 1.7.26 might be release to unblock anyone downstream wanting to use slf4j in a pure Java 9+ with modules application??? i'm specifically referring to this https://github.com/qos-ch/slf4j/pull/184 2) if 1.7.26 is not going to be release, any update on then 1.8.0 will be finally released? As the 1st alpha was Apr 2017 and last beta Mar 2018. Any blocking defects, blocking dependencies or outstanding testing that needs to be done? Any assistance needed? Cheers, Downstream Consumer

1 0

[JIRA] (SLF4J-428) automatic module name for jul-to-slf4j contains illegal token
by QOS.CH (JIRA) 05 Dec '18

05 Dec '18

[ https://jira.qos.ch/browse/SLF4J-428?page=com.atlassian.jira.plugin.system.… ] Gili commented on SLF4J-428: ---------------------------- Ceki, The JDK 11 implementation lines up with my interpretation of the specification. I went one step further. I downloaded the latest version of JDK 9 from [https://jdk.java.net/archive/] (version 9.0.4) and it compiled just fine against both the testcase and jul.to.slf4j. So, are we able to put back the module name to *jul.to.slf4j*? > automatic module name for jul-to-slf4j contains illegal token > ------------------------------------------------------------- > > Key: SLF4J-428 > URL: https://jira.qos.ch/browse/SLF4J-428 > Project: SLF4J > Issue Type: Bug > Components: jul-to-slf4j > Affects Versions: 1.8.0-beta1 > Reporter: Peter-Josef Meisch > Assignee: Ceki Gülcü > Fix For: 1.8.0-beta2, 1.8.0-beta3 > > Attachments: jpms-testcase.zip > > > the automatic module name that is created in Java 9 for the jul-to-slf4 jar is _jul.to.slf4j(a)1.8.0-beta1_. This contains the token *to* which is a reserved word in Java 9 so the generated name cannot be used in requires statements in modul-info.java files of projects using jul-to-slf4j and inhibits migration of projects to Java 9. > This should be modified by adding > {{Automatic-Module-Name: jul_to_slf4j}} > to the manifest for the archive. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0