4 ms·

On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from

On the other hand, you don't know what vulnerabilities are hidden in your own code and just haven't been discovered yet, and you're one fuzzing attack away from a vulnerability being discovered/exploited.

tester756 5y ago
What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.
- bob1029 5y ago
  > Not everything is don't roll your own crypto. Even for crypto, I have had people give me trouble for daring to use Microsoft's public & documented implementations of SHA256 and CSPRNG to derive session secrets. It's almost as if directly interacting with any crypto primitives is tantamount to rolling your own crypto these days.
  - dharmab 5y ago
    But splat 20 lines of obtuse openssl commands into a bash script and no one bats an eye!
- ineedasername 5y ago
  >What if there are none? The problem is that "There are no bugs" approaches an unproveable statement as a codebase grows into even a modest size. It doesn't matter if you're a 10x developer or not, you aren't always going to immediately see all the implications and edge cases of a few hundred++ (at least) moving pieces the first time around with new code, and each additional piece adds a non-linear amount of complexity. That doesn't mean you never roll your own version of something, it just means that you should either be very very good or have a lot of experience (or both) when making that decision for anything that's non-trivial. (And deciding what is/isn't trivial is its own decision too)
  - mro_name 5y ago
    you're in responsibility land then. That's not where they buy IBM to avoid getting fired. You get paid not for being smart, but for just doing responsibility for standard engineering. Plain craft. And do it seriously, not for admiration but payment.
    - ineedasername 5y ago
      Ah, responsibility land. More freedom to do as you want, and more risk because you can make mistakes and then have to face the consequences. Though it also often means you get to work on things that are a bit more interesting as well.
  - unixbane 5y ago
    youre doing something incredibly wrong if there is a threat that your system can be taken over by logging. and java enterprise object store late bound remote naming system registry garbage non-solutions to non-problems are the thing that is being done incredibly wrong here. your opinion is literally just an admission that you misunderstand basic software engineering principles like pretty much all programmers edit: on second thought, your sentiment makes sense in your world where most programmers live where most libs are doing asinine stuff because some enterprise dude needs it for his use case which could have been solved 500 other more saner ways. in that world, yes, you should always be afraid of anyhing, even a printf (hint hint DOTS soon)
    - ineedasername 5y ago
      You don't know what my world consists of, so I'm not sure where that comment comes from. My comment was addressing the general sentiment from the GP regarding the potential presence of bugs in software, not the log4j issue in particular-- plenty if other have done that and I won't rehash it. And of course your comment seems to ignitre the part of mine where I say that rolling your own version of something can be okay, but it's a decision to be made very carefully, along with my implication that trivial things are a different category. (your printf straw man would be about as trivial as it gets, so you're not making a string argument against my comment here) And this is not just for issues of bugs, but also time and resources. Why spend your time writing a complex library for something that is not part of the core of your business if a well established OSS alternative that has had countless eyes reviewing the codebase, and it can do all you need? I don't go rewriting grep or other utilities. I don't roll my own equivalent of a nearly decade old library like python Requests. I use well established tools from trusted sources and then get down to my real work. This is pretty much how most professions go about their jobs: use established tools, get to work. If there's a difference it's that many other engineering disciplines have had more than ~75 years to refine their established processes and basic tools.
- RedBeetDeadpool 5y ago
  Also, code written for libraries often need to factor in far more use cases and edge cases than code used for one part of your app. Its not too far fetched to say that there might not be any when you write your own because it might be significantly less encompassing.
layer8 5y ago
It really depends on the code. Proprietary custom code of course is less reviewed, but can also be much simpler and have a much smaller attack surface compared to a sprawling code-base like log4j. For me the trade-off is when understanding the complete architecture and important subtleties (often ill-documented) of a third-party library takes more time than writing reasonably straightforward custom code restricted to the current needs of the application.
- mumblemumble 5y ago
  For context, the log4j2 repository contains over 3,000 files and 175,000 lines of code. log4j-core alone has 1,100 Java files containing 82,000 lines of code. That's a pretty lush habitat for gremlins.
unixbane 5y ago
Logging isn't an application that typically results in RCE (outside charlatan code, and yes I'm referring to people who call themselves senior enterprise architects).

tester756 5y ago

What if there are none? It's not like library code is some magical stuff that only senior principal ninja 10x developers can comprehend Not everything is don't roll your own crypto.

bob1029 5y ago
> Not everything is don't roll your own crypto. Even for crypto, I have had people give me trouble for daring to use Microsoft's public & documented implementations of SHA256 and CSPRNG to derive session secrets. It's almost as if directly interacting with any crypto primitives is tantamount to rolling your own crypto these days.
- dharmab 5y ago
  But splat 20 lines of obtuse openssl commands into a bash script and no one bats an eye!
ineedasername 5y ago
>What if there are none? The problem is that "There are no bugs" approaches an unproveable statement as a codebase grows into even a modest size. It doesn't matter if you're a 10x developer or not, you aren't always going to immediately see all the implications and edge cases of a few hundred++ (at least) moving pieces the first time around with new code, and each additional piece adds a non-linear amount of complexity. That doesn't mean you never roll your own version of something, it just means that you should either be very very good or have a lot of experience (or both) when making that decision for anything that's non-trivial. (And deciding what is/isn't trivial is its own decision too)
- mro_name 5y ago
  you're in responsibility land then. That's not where they buy IBM to avoid getting fired. You get paid not for being smart, but for just doing responsibility for standard engineering. Plain craft. And do it seriously, not for admiration but payment.
  - ineedasername 5y ago
    Ah, responsibility land. More freedom to do as you want, and more risk because you can make mistakes and then have to face the consequences. Though it also often means you get to work on things that are a bit more interesting as well.
- unixbane 5y ago
  youre doing something incredibly wrong if there is a threat that your system can be taken over by logging. and java enterprise object store late bound remote naming system registry garbage non-solutions to non-problems are the thing that is being done incredibly wrong here. your opinion is literally just an admission that you misunderstand basic software engineering principles like pretty much all programmers edit: on second thought, your sentiment makes sense in your world where most programmers live where most libs are doing asinine stuff because some enterprise dude needs it for his use case which could have been solved 500 other more saner ways. in that world, yes, you should always be afraid of anyhing, even a printf (hint hint DOTS soon)
  - ineedasername 5y ago
    You don't know what my world consists of, so I'm not sure where that comment comes from. My comment was addressing the general sentiment from the GP regarding the potential presence of bugs in software, not the log4j issue in particular-- plenty if other have done that and I won't rehash it. And of course your comment seems to ignitre the part of mine where I say that rolling your own version of something can be okay, but it's a decision to be made very carefully, along with my implication that trivial things are a different category. (your printf straw man would be about as trivial as it gets, so you're not making a string argument against my comment here) And this is not just for issues of bugs, but also time and resources. Why spend your time writing a complex library for something that is not part of the core of your business if a well established OSS alternative that has had countless eyes reviewing the codebase, and it can do all you need? I don't go rewriting grep or other utilities. I don't roll my own equivalent of a nearly decade old library like python Requests. I use well established tools from trusted sources and then get down to my real work. This is pretty much how most professions go about their jobs: use established tools, get to work. If there's a difference it's that many other engineering disciplines have had more than ~75 years to refine their established processes and basic tools.
RedBeetDeadpool 5y ago
Also, code written for libraries often need to factor in far more use cases and edge cases than code used for one part of your app. Its not too far fetched to say that there might not be any when you write your own because it might be significantly less encompassing.

layer8 5y ago

It really depends on the code. Proprietary custom code of course is less reviewed, but can also be much simpler and have a much smaller attack surface compared to a sprawling code-base like log4j. For me the trade-off is when understanding the complete architecture and important subtleties (often ill-documented) of a third-party library takes more time than writing reasonably straightforward custom code restricted to the current needs of the application.

mumblemumble 5y ago
For context, the log4j2 repository contains over 3,000 files and 175,000 lines of code. log4j-core alone has 1,100 Java files containing 82,000 lines of code. That's a pretty lush habitat for gremlins.

unixbane 5y ago

Logging isn't an application that typically results in RCE (outside charlatan code, and yes I'm referring to people who call themselves senior enterprise architects).