Log4jmemes.com: for those of us that need a laugh
31–40 of 115 posts
Re: Log4jmemes.com: for those of us that need a laugh
#32Earlier quoted context omitted.
I don't have an article but here's a super quick rundown. Log4j is a very common logging framework used in java. It very often gets pulled in along with other dependencies, so it's easy to be using it without even realizing it. It has a feature that allows it to download and run code just by logging specially formatted strings. So if someone get cause your server to log these strings, it will run whatever code they w…
Okay, I know I am not a Real Programmer, but even I know that user content is to be Not Trusted. Isn't it like a Security 101 principle that user content is always potentially dangerous, and to be treated accordingly?
Re: Log4jmemes.com: for those of us that need a laugh
#33Re: Log4jmemes.com: for those of us that need a laugh
#34This is going to the brave souls who were on call the week this happened! I am not sure if they can block me on firms internal chats :) Jokes apart, a big kudos to those who were on call :)
Re: Log4jmemes.com: for those of us that need a laugh
#35On a serious note, I think it's a good time to remember to donate some $ to open source, especially the Apache foundation for their incredible work over the years!
There are of course many worse causes, but among umbrella organisations which just exist to provide some services to Free Software projects, Apache doesn't stand out as particularly good and I doubt that "Security vulnerabilities due to our lacklustre oversight drove a big increase in donations" is the lesson we ought to provide.
Re: Log4jmemes.com: for those of us that need a laugh
#36On a serious note, I think it's a good time to remember to donate some $ to open source, especially the Apache foundation for their incredible work over the years!
All money donated to Apache gets spend on their own infrastructure and salaries, etc.
Re: Log4jmemes.com: for those of us that need a laugh
#37The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…
Just one example.
Re: Log4jmemes.com: for those of us that need a laugh
#38The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&1 - using systemd? use journalctl - using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something Real question: why would an application need to know where its logs go? This is not in the business…
I think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and it can even be dangerous as Docker - at least for a long time - did not implement proper backpressure and instead dropped logs). log4j allows libraries to implement logging and allow the end user to worry about where the logs go, at the application level, usual…
In the Java world before cloud-native we had application servers like Tomcat and JBoss which typically used something like log4j (log4j-core package) to configure what gets logged and where the logs should be shipped to. These application servers where shared and usually hosted more than 1 application. Hence the need to do contextual lookups (jndi and others) to determine log routing or enrich log messages with contextual information.
Applications or libraries running inside these application servers would only implement a logging api (log4j-api package) which is just a facade so every application can write implementation-independant logging and let the application server provide the implementation and configuration.
Now in the cloud-native/12-factor world, the industry has moved away from application servers (or embeds an app-specific server in the container) so it makes sense to just log to stdout and let the container orchestration handle log shipping and filtering. The former role of log4j is now mostly handled by Fluentd, Logstash, Filebeat and friends.
Log4j still has a place though: Having the ability to use ENV vars or commandline flags to influence log levels and packages is still a nice to have. And one feature that is often overlooked is the ability to set contextual information per request. For example authentication middleware can set a userId or requestId in the request context and every log message within the request handling automatically gets logged with that metadata, avoiding the need to pass all this contextual information manually in every log.info(...) statement.
Re: Log4jmemes.com: for those of us that need a laugh
#39Re: Log4jmemes.com: for those of us that need a laugh
#40Thanks for laugh. Corporate VPN: "This site is blocked due to a security threat."
IT: Domain too new, so we're blocking it out of abundance of caution.
(Works for blocking new and targeted threats, but you get this false-positive block.)