5 ms·

You mean the the reaction to jndi logging RCE for log4j has been way too seriously? What's the basis of this assessment? Logging library fetching remote code

You mean the the reaction to jndi logging RCE for log4j has been way too seriously? What's the basis of this assessment? Logging library fetching remote code and inject to local application runtime. Seems a pretty bad idea for any people with decent amount of programming experience, right? Or I missed something.

csande17 5y ago
People are mad that someone created a Go library mocking the (obviously terrible) log4j behavior. How dare you make fun of the hardworking log4j developers, or the programming community that accepted their outrageously overcomplicated library without question? They're trying their best!
- crest 5y ago
  I'm sure the log4j developers have just as much potential as the code they're sort of maintaining. If you let them into your codebase you get federated remote code updates for free.
- Ygg2 5y ago
  Honestly, I'm a bit miffed. It's a damned if you do, damned if you don't scenario for OSS. Don't add feature X that other log library might add or has added, your lib is bad. Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen. It all starts with little changes. Allow us to show colors in console... Allow us more formatting options... We need to display remotely added class... We need JNDI access...
  - Nursie 5y ago
    I think at some point (like introducing the ability to fetch resources off a network in your logging library) you need to step back and say "let's put this in its own, optional extra module". There are ways to manage this sort of stuff.
  - josefx 5y ago
    > Oh and RCE might happen. You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough. If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.
    - Ygg2 5y ago
      Log4j maintainers didn't like the feature, they added it for backwards compatibility. > Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
      - NovaX 5y ago
        It was added by these maintainers in 2.x and did not exist in 1.x. The maintainers are also different from 1.x developers and took the brand. They may regret their past decisions, but it was is irresponsible to claim that it was not their fault and added for backward compatibility.
  - monkeybutton 5y ago
    There isn't a benefit to OSS projects all competing for the same audience and bloated feature set. Picking a subset, being opinionated about it and the implementation isn't wrong. For developers, there is such a thing as picking the right tool for the job, even if it isn't your favourite one you usually use.
    - mcfedr 5y ago
      As much as people moan about npm community, it does give you many choices and you can avoid complicated massive libs
      - Ygg2 5y ago
        ...By adding thousands of libs, turning node_modules into a multi GB folder. Oh, and each of which can be compromised by an unscrupulous actor. Good luck auditing that.
        p2t2p 5y ago
        Like if any other thing with automatic package management is any better. .m2/repository is 5 gb on my machine. Rust crates? Go packages that are neatly tucked away too? Node just makes it visible and in your face by putting the node_modules in you project directory. Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.

csande17 5y ago

People are mad that someone created a Go library mocking the (obviously terrible) log4j behavior. How dare you make fun of the hardworking log4j developers, or the programming community that accepted their outrageously overcomplicated library without question? They're trying their best!

crest 5y ago
I'm sure the log4j developers have just as much potential as the code they're sort of maintaining. If you let them into your codebase you get federated remote code updates for free.
Ygg2 5y ago
Honestly, I'm a bit miffed. It's a damned if you do, damned if you don't scenario for OSS. Don't add feature X that other log library might add or has added, your lib is bad. Add a feature X that other log library has, now you support it for the lifetime of universe. Oh and RCE might happen. It all starts with little changes. Allow us to show colors in console... Allow us more formatting options... We need to display remotely added class... We need JNDI access...
- Nursie 5y ago
  I think at some point (like introducing the ability to fetch resources off a network in your logging library) you need to step back and say "let's put this in its own, optional extra module". There are ways to manage this sort of stuff.
- josefx 5y ago
  > Oh and RCE might happen. You added a feature that can load plugins and query any kind of data based on user provided strings, this is completely unexpected and never happened before. What to call it? How about SQL injection attack, sounds about fancy enough. If you implement feature requests without thinking about the design and security implications it has you are doomed to repeat history.
  - Ygg2 5y ago
    Log4j maintainers didn't like the feature, they added it for backwards compatibility. > Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns.
    - NovaX 5y ago
      It was added by these maintainers in 2.x and did not exist in 1.x. The maintainers are also different from 1.x developers and took the brand. They may regret their past decisions, but it was is irresponsible to claim that it was not their fault and added for backward compatibility.
- monkeybutton 5y ago
  There isn't a benefit to OSS projects all competing for the same audience and bloated feature set. Picking a subset, being opinionated about it and the implementation isn't wrong. For developers, there is such a thing as picking the right tool for the job, even if it isn't your favourite one you usually use.
  - mcfedr 5y ago
    As much as people moan about npm community, it does give you many choices and you can avoid complicated massive libs
    - Ygg2 5y ago
      ...By adding thousands of libs, turning node_modules into a multi GB folder. Oh, and each of which can be compromised by an unscrupulous actor. Good luck auditing that.
      - p2t2p 5y ago
        Like if any other thing with automatic package management is any better. .m2/repository is 5 gb on my machine. Rust crates? Go packages that are neatly tucked away too? Node just makes it visible and in your face by putting the node_modules in you project directory. Besides, what’s the alternative? Write stuff yourself? Put stuff in language stdlib? Even minimal service requires _a lot_ of things to do minimal stuff.