14 ms·

Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign

Thanks to all Log4j developers. As users of your free software since ~20 years, we're sure that, if this vuln disclosure had been better and there were no sign of widespread in-the-wild exploitation, you would have done a better job at patching it, and a single release would have been enough. We won't hold a grudge against you; open source means collaboration, and you don't blame hard-working people that give away their software for free for honest mistakes. Your software still did far more good than bad to the software world. Thanks!

jacquesc 5y ago
Thanks to Log4J developers for turning me off to Java 20yrs ago due to their horrible API design and developer experience. Does not shock me that this security vulnerability happened, but it did shock me that so many people kept using this awful library. I thus enjoyed a development career (mostly) free from this kind of needless pain and suffering.
- dang 5y ago
  Please don't cross into personal attack. You can make your substantive points without swipes, and that's the spirit we want here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- mml 5y ago
  The options at the time were even worse.
- Hallucinaut 5y ago
  log4j2 has little to do with the log4j you claim turned you off 20 years ago and almost no one works directly to the logging library API rather than an slf4j facade.
  - jacquesc 5y ago
    Fair enough. But to me it was the smell of a toxic Java ecosystem, where people had to use crappy software even though they knew how bad it was. It took a simple problem and turned it into a clusterfuck of configuration and complexity.
    - ivan_gammel 5y ago
      Java ecosystem is rich and much more developed than anything else. There are plenty of better solutions on the market, both open source and commercial. There exist alternatives to log4j for a while, e.g. logback, which is the default option for Spring Boot applications - there was absolutely no need to use log4j2. It was always a free choice. It is worth mentioning, that any even very basic solution always has a possibility to shoot in the leg, and only professionalism of the developers of the client code can avoid it, so the real reason why this is happening now on a massive scale is that Java world is big and has probable hundreds of thousands, if not millions of developers, who do not have enough knowledge or experience to write better code, understanding all the possible side effects and other consequences of their decisions. This was going to happen eventually. It will happen again, but maybe next time it will be a Python or TypeScript library. Would it be right to call their ecosystems toxic? I honestly do not know. But let's at least have some respect for people who have built it, almost for free.
      - jacquesc 5y ago
        Why can't we point out that the "default" choice for most java shops is one that is massively overcomplicated, a nightmare to use, and subject to security disasters like we are seeing? This wasn't "unknowable". Using overly complicated, poorly designed software is a direct cause. Why should I show respect for software I hate using and that causes problems for the entire tech community? I appreciate that they built it for free. I write open source code too, and glady accept criticism if I release something that sucks (which I do often) This saga is a lesson in choosing the right tech, and switching off libraries built for use cases 100x more complex than what 99.9% users need.
        samhw 5y ago
  - ashtonkem 5y ago
    Slf4j is one of the two examples I point to for really great java design. It's broken down into one jar for the no-op interfaces, and other jars for the various implementations. This lets library owners instrument their libraries for logging without having to make a final decision on the actual logging library and its settings. It's great. The other example for those that are curious is micrometer. The basic API and the implementations (prometheus, statsd, etc.) are separate jars.
- intro-b 5y ago
  damn i checked ur profile and ur actually based respect
jiggawatts 5y ago
I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some mysterious reason those incidents were simply ignored by security teams world wide. Instead of chilling them to the bone, they simply shrugged their shoulders and said "Well, we don't use NPM... I think. Probably?" and went on with their paper-pushing or whatever it is CISOs do these days. If you think Log4j is bad, wait until Rust gets popular and has something similar happens with a commonly used crate. How would you scan for a vulnerability in compiled code that doesn't even have separate module files? I had to help an organisation with log4j that had on the order of 5K distinct executables/applications across 3K servers on two clouds and three on-prem networks. At least with log4j it's a simple matter of finding JAR files and scanning their contents. They're just zip files! With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. Introspection and post-shipping updates for security are mandatory. Rust and Go like to pretend they aren't, because they originate from organisations that are in total, end-to-end control of the software on their own network. Google famously uses a monorepo and can build everything they run from scratch in short order. The shortcuts they can take with their post-release management will never work for ordinary organisations. Never. So let this be a lesson: Log4j was made for a language that at least allowed us all to find the issue and fix it ourselves. We have Sun's forward-thinking and the enterprise-friendliness of the Java ecosystem to thank for that.
- c-cube 5y ago
  If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?
  - tatersolid 5y ago
    In commercial software the customers don’t have the source files…
diob 5y ago
So happy to see this as the top comment. We need way more positivity in tech.
- wyager 5y ago
  Do we? Or does "positivity" enable insecure software because there isn't enough social pressure against making dangerous engineering decisions?
  - watwut 5y ago
    Are you saying there would be more security issues if we thanked maintainers more?
    - wyager 5y ago
      Only if we thank maintainers specifically after they get bad publicity for a big security issue.
- throwuxiytayq 5y ago
  I was here just to say this - seeing this comment at the top of the thread restores my faith in people.
- vmception 5y ago
  I thought it was satire, but I guess that says more about me
devit 5y ago
Wouldn't really thank them. They found a way to make several catastrophic mistakes while writing a logging solution (one of the most trivial kinds of software) in a memory-safe language. It's surprising they manage to breathe properly and thus survive.

jacquesc 5y ago

Thanks to Log4J developers for turning me off to Java 20yrs ago due to their horrible API design and developer experience. Does not shock me that this security vulnerability happened, but it did shock me that so many people kept using this awful library. I thus enjoyed a development career (mostly) free from this kind of needless pain and suffering.

dang 5y ago
Please don't cross into personal attack. You can make your substantive points without swipes, and that's the spirit we want here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
mml 5y ago
The options at the time were even worse.
Hallucinaut 5y ago
log4j2 has little to do with the log4j you claim turned you off 20 years ago and almost no one works directly to the logging library API rather than an slf4j facade.
- jacquesc 5y ago
  Fair enough. But to me it was the smell of a toxic Java ecosystem, where people had to use crappy software even though they knew how bad it was. It took a simple problem and turned it into a clusterfuck of configuration and complexity.
  - ivan_gammel 5y ago
    Java ecosystem is rich and much more developed than anything else. There are plenty of better solutions on the market, both open source and commercial. There exist alternatives to log4j for a while, e.g. logback, which is the default option for Spring Boot applications - there was absolutely no need to use log4j2. It was always a free choice. It is worth mentioning, that any even very basic solution always has a possibility to shoot in the leg, and only professionalism of the developers of the client code can avoid it, so the real reason why this is happening now on a massive scale is that Java world is big and has probable hundreds of thousands, if not millions of developers, who do not have enough knowledge or experience to write better code, understanding all the possible side effects and other consequences of their decisions. This was going to happen eventually. It will happen again, but maybe next time it will be a Python or TypeScript library. Would it be right to call their ecosystems toxic? I honestly do not know. But let's at least have some respect for people who have built it, almost for free.
    - jacquesc 5y ago
      Why can't we point out that the "default" choice for most java shops is one that is massively overcomplicated, a nightmare to use, and subject to security disasters like we are seeing? This wasn't "unknowable". Using overly complicated, poorly designed software is a direct cause. Why should I show respect for software I hate using and that causes problems for the entire tech community? I appreciate that they built it for free. I write open source code too, and glady accept criticism if I release something that sucks (which I do often) This saga is a lesson in choosing the right tech, and switching off libraries built for use cases 100x more complex than what 99.9% users need.
      - samhw 5y ago
- ashtonkem 5y ago
  Slf4j is one of the two examples I point to for really great java design. It's broken down into one jar for the no-op interfaces, and other jars for the various implementations. This lets library owners instrument their libraries for logging without having to make a final decision on the actual logging library and its settings. It's great. The other example for those that are curious is micrometer. The basic API and the implementations (prometheus, statsd, etc.) are separate jars.
intro-b 5y ago
damn i checked ur profile and ur actually based respect

jiggawatts 5y ago

I lay any blame squarely at the feet of IT security of large organisations that were entirely unprepared to update a widely used dependency that wasn't an operating system or a runtime. Windows, Linux, Java, and .NET are all commonly updated, but "modules" aren't. This wasn't just a predictable scenario, it was predicted. Or more accurately, it has occurred already repeatedly in the NPM ecosystem, but for some mysterious reason those incidents were simply ignored by security teams world wide. Instead of chilling them to the bone, they simply shrugged their shoulders and said "Well, we don't use NPM... I think. Probably?" and went on with their paper-pushing or whatever it is CISOs do these days. If you think Log4j is bad, wait until Rust gets popular and has something similar happens with a commonly used crate. How would you scan for a vulnerability in compiled code that doesn't even have separate module files? I had to help an organisation with log4j that had on the order of 5K distinct executables/applications across 3K servers on two clouds and three on-prem networks. At least with log4j it's a simple matter of finding JAR files and scanning their contents. They're just zip files! With languages that output a single binary by default such as Rust and Go, we would have been screwed. No way to scan, no way to self-help update. Introspection and post-shipping updates for security are mandatory. Rust and Go like to pretend they aren't, because they originate from organisations that are in total, end-to-end control of the software on their own network. Google famously uses a monorepo and can build everything they run from scratch in short order. The shortcuts they can take with their post-release management will never work for ordinary organisations. Never. So let this be a lesson: Log4j was made for a language that at least allowed us all to find the issue and fix it ourselves. We have Sun's forward-thinking and the enterprise-friendliness of the Java ecosystem to thank for that.

c-cube 5y ago
If you still have the source code for your rust code, it contains the lock file. Look in there and you'll see all dependencies and their version. Why do you want to look at the binary instead?
- tatersolid 5y ago
  In commercial software the customers don’t have the source files…

diob 5y ago

So happy to see this as the top comment. We need way more positivity in tech.

wyager 5y ago
Do we? Or does "positivity" enable insecure software because there isn't enough social pressure against making dangerous engineering decisions?
- watwut 5y ago
  Are you saying there would be more security issues if we thanked maintainers more?
  - wyager 5y ago
    Only if we thank maintainers specifically after they get bad publicity for a big security issue.
throwuxiytayq 5y ago
I was here just to say this - seeing this comment at the top of the thread restores my faith in people.
vmception 5y ago
I thought it was satire, but I guess that says more about me

devit 5y ago

Wouldn't really thank them. They found a way to make several catastrophic mistakes while writing a logging solution (one of the most trivial kinds of software) in a memory-safe language. It's surprising they manage to breathe properly and thus survive.