As a Python developer, I am so happy right now.
But are you really really happy, mate?
No, he is just long long happy.
Log4jmemes.com: for those of us that need a laugh
51–60 of 115 posts
Re: Log4jmemes.com: for those of us that need a laugh
#52As a Python developer, I am so happy right now.
Today I was tasked to audit our system for uses of log4j and I was so relieved to learn all our services are written in Go or PHP.
Also noticed we were continously scanned for the vulnerability (random "jndi:ldap" in requests) from different IPs, some from China
Re: Log4jmemes.com: for those of us that need a laugh
#53and i thought that humor was against the regulations here...
Re: Log4jmemes.com: for those of us that need a laugh
#54Is there any comprehensive article that covers what log4j is and just what happened that is so critical that seems to have set the entire world on fire? Disclaimer: I have never heard of or used log4j before in my life.
This comment (1) posted 5 days ago on HN does a very well job of explaining it.
Re: Log4jmemes.com: for those of us that need a laugh
#55The 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…
I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.
Re: Log4jmemes.com: for those of us that need a laugh
#56The 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…
Imagine a large system that has lots of log.DEBUG statements in its code. If you turn on DEBUG logging, then it logs, say, 10 TB/day. This is a meaningful cost for most organisations, also it is hard to search. Also, you mostly don't need debug level logs. One thing e.g. a logging library gives you is that you can toggle log levels very granularly, e.g. you turn on debug logging for a specific class. Just one example…
And with templates, you do log.debug("{} {}", var1, var2, someThrowable) and don't even call toString on those unless you're actually logging them.
Compare this to system.err.println("DEBUG: " + var1 + " " + var2 + " " + someThrowable.stackTrace()) -- that creates a StringBuilder, allocates a potentially large String, and then sends it on.
There are numerous performance impacts (improvements) at using a logging framework that doesn't log or allocate a String to log what it doesn't need to.
Re: Log4jmemes.com: for those of us that need a laugh
#57Earlier quoted context omitted.
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…
I'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.
The libraries being able to log what they do helps a lot when debugging production issues. The application does not see inside cache library or hibernate or what not. They themselves being able to log what they do inside helps a lot.
Re: Log4jmemes.com: for those of us that need a laugh
#58Earlier quoted context omitted.
I was thinking of this one: https://twitter.com/chfourchfour/status/1469412054549286928
The piece of paper LOL
I know it's a joke but since it's just a string any system that does character recognition of images and logs that with log4j could be hit.
So posting images of paper with this string may indeed get hits.
One of the most incredible vulnerabilities ever.
Re: Log4jmemes.com: for those of us that need a laugh
#59Re: Log4jmemes.com: for those of us that need a laugh
#60On 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!
You seriously think that the multi-million dollar Apache foundation, which oversaw this mess and whose "Apache Way" supposedly should have prevented it but in fact is a joke, needs more money? 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 vulnerabiliti…
You would expect the foundation to prevent bugs? When did Apache even even claimed to be bug free?