Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I heard Log4j core is vulnerable according to https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
So I need a fix to get rid of vulnerabilities from my services!
I am trying to bump up log4j from older versions to 2.15.0
I can manually upgrade the dependencies but the problem is I don't know, is there any dependency that is downloading the log4j older version or not!
So I want some solution that will just upgrade the log4j dependency in my projects either they are direct or transitive :)
[UPDATE] Log4j rolled out a new version 2.17.0 with some more security fixes and recommended using 2.17.0 in systems :)
[UPDATE]
Log4j released one more build which is 2.16.0 with one more security fix!
I found the dirty fix!
Just add the following code block in your build.gradle and this will upgrade your log4j libs to 2.16.0
regardless of the dependency is direct or transitive
configurations.all {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
if (details.requested.group == 'org.apache.logging.log4j') {
details.useVersion '2.17.0'
}
}
}
Please find the solution
Upgrade Apache log4j version to 2.15.0 (released date: Friday,
December 10, 2021) , if you are using Apache log4j and the version
is less than 2.15.0. Currently 2.15.0 is outdated. Use 2.16.0
On Dec13th, apache has introduced new version of log4j - Log4j 2.16.0,
this is more reliable to use.
Also check the JVM version, if lower than this may get impacted.
Java 6 – 6u212
Java 6 – 6u212
Java 7 – 7u202
Java 8 – 8u192
Java 11 - 11.0.2
Related
This question already has answers here:
Log4j vulnerability - Is Log4j 1.2.17 vulnerable (was unable to find any JNDI code in source)?
(3 answers)
Closed 1 year ago.
I've got a very old version of Solr and I've been trying to see if it is affected by the Log4Shell vulnerability that everybody is freaking out about (CVE-2021-44228).
The CVE only seems to apply to later versions, but a colleague doesn't buy it, so I'm trying to figure out the truth.
I'm about 95% sure this is fine for older versions of Log4j. Three reasons:
I'm on version 1.2. I found the Log4j JAR file on my system, unzipped it, and looked for anything mentioning JNDI:
find / -iname '*log4j*'
unzip /etc/opt/jetty/lib/ext/log4j-1.2.17.jar | grep -i jndi
That brought back nothing, so I feel pretty good there. The CVE says that you'd normally find something by looking in the JAR file. It suggests you do:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
That wouldn't do anything for me.
I dug through the changelog for Log4j. It says for version 2.0-beta9:
Add JNDILookup plugin. Fixes LOG4J2-313. Thanks to Woonsan Ko.
So I think it's safe to say that JNDI didn't exist in Log4j before then. The Jira ticket that added it is here.
I checked the old manual for version 1.2 and compared it to the latest version. In the latest, there's a section for "Lookups" that explains how JNDI works. In version 1.2, that section just isn't there.
I think it's...fine?
Ralph Goers (Apache Log4J maintainer) said:
There are two aspects to this vulnerability.
Log4j 2’s lookup mechanism (property resolver) was being performed on the message text being logged. This meant that if applications are
logging user input (almost everyone does) a user could cause the
Lookup mechanism to be invoked.
Log4j 2 supports JNDI in various places, including as a lookup. JNDI itself is horribly insecure. The combined effect of these is what
makes it a critical severity issue for Log4j 2. Log4j 1, as well as
Logback, both have components that use JNDI and neither do anything to
limit the JNDI vulnerabilities. In the case of Log4j 1 it is the JMS
Appender. The exposure is smaller but it is still there. If someone
can gain access to the logging configuration they could conceivably
cause bad things to happen.
So the conclusion is that Log4J 1.x is secure and not impacted by the Log4Shell unless you use JMS appender. In that case you have to analyze what you do in the appender.
As VSCode seems to contain elements of chromium (and thus FreeType), is it vulnerable to CVE-2020-15999?
This is a heap buffer overflow in FreeType < 2.10.4 with potential to remote code execution. If so, is there already a planned release date for a patch?
I know this is an unusual question for StackOverflow, but the official repository linked here via issue template, so I guess this would be the correct place to ask.
Best regards
The Node.js maintenance policy is described by the Node.js Long-term Support Working Group
I suppose that maintanence release will get lesser updates. But what are the exact differences between LTS and maintenance?
Answered by a Node.js Foundation Member
There are both Active + Maintenance LTS
The first 18 months are active, the last 12 are maintenance.
During active we try and backport as much as reasonably possible.
During Maintenance we only backport security fixes and major
unavoidable bug fixes
Source: https://github.com/nodejs/LTS/issues/76
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I am learning Spring boot recently, there are too much magic in it. I find most of the resource, include the official website, is focused on how to use it, not explain how it works. Could anyone share such resources?
UPDATE:
Maybe my description cause some confusion(close votes), I am actually looking for answer to questions like below:
What will happen when boot find "org.springframework.boot:spring-boot-starter-web" in pom.xml? Does it add Tomcat lib jar into my classpath? Will web.xml be generated? (documents said boot do not generate code)
What will happen when boot find "org.springframework.boot:spring-boot-starter-data-jpa", will persistence.xml be generated? How boot create a repository instance based on the database driver dependency in pom.xml?
...
Spring Boot does not generate any code at all, all configuration is performed programmatically. So for example, there won't be a web.xml file that configures your servlets, instead the servlet 3.0 API will be used to register them in code.
The starter POMs provide a convenient way to add jars to your classpath, but they do not themselves do anything. For example, spring-boot-starter-web will add Tomcat and Spring MVC jars, spring-boot-starter-data-jpa will add Hibernate and Spring Data JPA etc.
Once you have relevant jars on your classpath, Spring Boot will attempt to auto-configure things for you. When it starts it consults META-INF/spring.factories files to find potential configuration (here is an example).
Each configuration is tried in turn to see if it can be applied. Configurations use #Condition annotations to limit when they apply. For example, the HibernateJpaAutoConfiguration only applies when certain Hibernate classes can be found (see here). Auto-configurations are just typical Spring #Configuration classes, so you can take a look at the source code to see what is actually happening.
The reference documentation (and specifically Appendix B) might also help.
Based upon my intial understanding my answer is given below.
Basically, Spring Boot is helping in providing dependencies based upon your requirements.
We don't need to manage pom.xml.
We just need to include correct base project of Spring Boot.
Rest all of things can be done without Spring Boot as well, like all configuration with Annotation only.
Below given link may help you more.
http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/html/index.html
Did a simple experiment with the jars inclusion:
First run the application without the "spring-boot-starter-web" jar, the "spring-boot" application will be standalone application.
Now add the "spring-boot-starter-web", the "spring-boot" application will starts the "tomcat" container.
2 things here, based on my observation.
The pom.xml is declaration to what jars to be added.
Once the SpringBoot application started, first it will check the "Auto-configurations", once the "spring-boot-starter-web" is in the classpath, this will start the tomcat automatically.
For any more information, we need to run the "spring-boot" application in --debug option.
This will publish the "AUTO-CONFIGURATION REPORT" which will be helpful.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
We started using servicestack v4, rest assured that there where no licensing limits on the client. At least that's what I could read out of servicestack's download page.
We are building our project according to mythz' answer to this question on servicestack how to structure an api.
The generic client works (so far) as expected without setting a license, but when a colleague created a test-client against the service, using the .Dump() method, he ran into this exception:
The free-quota limit on '20 ServiceStack.Text Types' has been reached. Please see https://servicestack.net to upgrade to a commercial license or visit https://github.com/ServiceStackV3/ServiceStackV3 to revert back to the free ServiceStack v3.
Let it be said: the .Dump()-method is not the issue here, we could do without it :) But, I really dislike these sudden exceptions! They suddenly blows up your project, reaching some sort of licensing limit. The last time something like this happended, it was inside an ormlite integration test. Everything works just fine, then KABOOM, you have to add your license to your NUnit test project.
Is there any more gotchas in this framework? Can we recommend to consumers of our API to use the servicestack client to connect, or will it suddenly come back and haunt us? I fully understand the need for licensing the framework, but this all boils down to me not trusting the framework which now is the core of my service!
What can you freely use the client-package and it's dependencies to, and what can you not?
Do you have any words of reconciliation? Will the ServiceStack.Client-mines be removed, or should we recommend all customers using the servicestack.client-package to buy a license to avoid their application from suddenly crashing if we add another property in a POCO-class? If ServiceStack.Client is not a "free", rather a "free-but" package, how can I know when calling a method if it's under some sort of quota or not?
As of v4.0.62 ServiceStack.Text is now free where now all restrictions have been removed from ServiceStack.Text as well as all client libraries depending on ServiceStack.Text including:
ServiceStack.Text
ServiceStack.Client
ServiceStack.HttpClient
ServiceStack.Stripe
(includng all *.Signed .NET Core *.Core versions of the above packages)
Where the above libraries no longer have any technical restrictions or need to register a license key in order to use them unrestricted.
All other free quotas in ServiceStack Server libraries are listed at: https://servicestack.net/download#free-quotas