6 ms·

Unless by "decent programmer" you mean a non-human programmer, he's right. This might be shocking to a flawless supercomputer AI such as yourself but humans ma

• nineteen999 8y ago
  Look back at how the original problem is specified. > imagine the format says [number of bytes to come] [the bytes]. Allocate an array with the specified size and then copy the rest of the message into it. Right? If your client came to you and said that was the specification, you'd be negligent to fail to point out the obvious flaw with the logic, wouldn't you?
  • Gaelan 8y ago
    IIRC Heartbleed was basically exactly that.
    • nineteen999 8y ago
      Heartbleed triggered a major audit and a fork (LibreSSL) of the OpenSSL codebase, wherein much of the code was found to be of less than stellar quality: "Unfortunately, the OpenSSL basket was being watched somewhat less than very carefully. Yeah, it has bugs, but surely somebody else will fix them. And worst case scenario, since everybody uses the same library, everybody will be affected by the bugs. Nobody wants to be alone". https://www.openbsd.org/papers/eurobsdcon2014-libressl.html https://www.openbsd.org/papers/eurobsdcon2014-libressl.html So I'm pretty sure the one example you have picked here reinforces my point.
  • saiya-jin 8y ago
    you... don't have much real world experience with coding, do you. Big teams, huge codebases that nobody groks completely, weird legacy code etc. All these create tons of sub-optimal implementations on various levels.
    • nineteen999 8y ago
      If there were easily exploitable buffer overflows in one of the weird, legacy C++ programs I and my team have to maintain, and we didn't take steps to protect that program from abuse, ambulances and fire engines for nearly 8 million people would never be called to their destinations nor arrive on time. Is that real world enough for you?
      • zeroname 8y ago
        That is entirely fallacious reasoning. Your programs could be full of exploitable bugs (and they probably are) yet nobody knows or cares enough to exploit them. OpenSSL had trivial errors unchecked and presumably unexploited for years.
        • nineteen999 8y ago
          Or maybe we know the program we inherited has flaws, and we don't connect it/publish its source code to the internet claiming it's fit for general purpose use, and we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. But you go ahead and believe it's because of dumb luck if you like.
          • zeroname 8y ago
            You made a simple If-this-then-that claim that was a non-sequitur, that's my only point. > we strive everyday to provide new mitigations and defense in depth to prevent its exploitation. I'm fairly confident that even if you didn't do that it wouldn't make much of a difference, because the likelihood of anyone attempting to exploit your particular niche program are quite low. > But you go ahead and believe it's because of dumb luck if you like. I didn't say it was dumb luck. The fact of the matter is that most software isn't hardened in the way you describe, for simple economical reasons.
            • nineteen999 8y ago
              Sorry where is the non-sequitur? The previous poster purported that I mustn't have much "real world" experience in coding, and I responded that I and my team wouldn't be entrusted to successfully maintain a program and network that coordinates emergency services first responders over a large land mass and number of people if that was the case. If you honestly think that emergency services infrastructure is less of a valuable target to a rogue operator than Internet Widgets Inc. or whatever then I think we are done here for now. This is all a huge over-reaction to my initial point which was; the format that the OP proposed was busted, and any good C/C++ programmer should notice that immediately rather than implement it blindly. If they can't do that then, yes, definitely stick to a managed language. Which I agree is good advice anyway. Thank you and have a nice day.