6 ms·

> A decent programmer would never... You might want to Google for ImageTragick. Or heartbleed. Or shell shock. Or Java deserialization. Or flash. But please, t

> A decent programmer would never... You might want to Google for ImageTragick. Or heartbleed. Or shell shock. Or Java deserialization. Or flash. But please, tell me more about what a decent programmer would never do.

nineteen999 8y ago
You and I evidently have different definitions of "decent programmer" then. It sounds like your standards are much lower.
- lagadu 8y ago
  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 make mistakes.
  - 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.
pas 8y ago
Decent programmers are also context dependent. For example when ImageMagick's delegate functionality was envisioned (before 1999 - that's the earliest page I was able to quickly found that mentions the feature), IT security was not taken that seriously. Basically Mitnick was just arrested (1995), multi user systems were all guarded and watched closely by bastard operators from hell like dragons sitting on a mountain of gold. And PHP was seen as harmless fun. And malware was thought of as boot sector viruses and even though the first worm (1988, the Morris) worked exactly like what people are harping about (buffer overrun), no one cared, because C++ was slow to compile, and managed runtimes are evil. And still no one cares. It takes some competence to stop using C, but it's easier to simply shout at those who point out the obvious. And when someone brings out the good old Therac-25 everyone starts to fall silent. (Even if healthcare accreditation is very expensive, it's expensive exactly because the whole IT field is still full of unverifiable code.)
- nineteen999 8y ago
  > For example when ImageMagick's delegate functionality was envisioned ... IT security was not taken that seriously Yes it might have been easy to get away with writing the OP's faulty specification into code back then. After 25 years of people screaming about the dangers of buffer/integer overflows, it's very hard for me to think that a serious C/C++ programmer could look at that specification and not see the issue before blindly committing it to code today. I suppose it could happen. OpenSSL (which everyone else here is crying about as an example) is also over 20 years old. > And still no one cares. It takes some competence to stop using C, but it's easier to simply shout at those who point out the obvious. Well imagine trying to rewrite the Linux kernel today in a memory safe language, without losing any support for any of the current target architectures. Or NetBSD even more so for that matter. Nobody has convinced me it could be done, and as of yet, it hasn't been. Throwing away C and C++ for good is fine - if you don't want to do much in the way right now of embedded programming, or working with sophisticated games engines (eg. UE4), just for fun. If you're not confident of the quality of the code, then maybe don't deliver it to for all and sundry saying its fit for purpose. And if you are confident, then check it again. That's all I'm saying.
  - 8y ago
ken 8y ago
And yet, look at all the billions (trillions?) of lines of code in the world which do not have a horrible security flaw. Heartbleed is notable because of its rarity. OpenSSL is over 500,000 lines of C, written by 500 contributors, and somehow it generally works pretty well. Maybe the phrase "a decent programmer would never" unfairly assigns blame to an individual's skill, but I think it would be fair to say that the programmers who designed and implemented these bugs were not doing decent work on the day that they made these mistakes. If our standards for C programmers don't include bounds checking of array access, what exactly do they include?
- zozbot123 8y ago
  The whole problem is that you only need one mistake in all those billions/trillions of LOC's, and your systems get 0wned. I'm pretty sure that "our standards for C programmers" don't include "programmer is guaranteed not to make any mistake, EVAR", whereas that's an entirely appropriate standard for automated, language-based security.
  - nineteen999 8y ago
    See the related article posted from Microsoft today; Microsoft: 70 percent of all security bugs are memory safety issues https://news.ycombinator.com/item?id=19138602 If we could get rid of that 70% that would be great, but it still leaves programmers doing other stupid shit in the other 30% of cases.

nineteen999 8y ago

You and I evidently have different definitions of "decent programmer" then. It sounds like your standards are much lower.

lagadu 8y ago
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 make mistakes.
- 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.

pas 8y ago

Decent programmers are also context dependent. For example when ImageMagick's delegate functionality was envisioned (before 1999 - that's the earliest page I was able to quickly found that mentions the feature), IT security was not taken that seriously. Basically Mitnick was just arrested (1995), multi user systems were all guarded and watched closely by bastard operators from hell like dragons sitting on a mountain of gold. And PHP was seen as harmless fun. And malware was thought of as boot sector viruses and even though the first worm (1988, the Morris) worked exactly like what people are harping about (buffer overrun), no one cared, because C++ was slow to compile, and managed runtimes are evil. And still no one cares. It takes some competence to stop using C, but it's easier to simply shout at those who point out the obvious. And when someone brings out the good old Therac-25 everyone starts to fall silent. (Even if healthcare accreditation is very expensive, it's expensive exactly because the whole IT field is still full of unverifiable code.)

nineteen999 8y ago
> For example when ImageMagick's delegate functionality was envisioned ... IT security was not taken that seriously Yes it might have been easy to get away with writing the OP's faulty specification into code back then. After 25 years of people screaming about the dangers of buffer/integer overflows, it's very hard for me to think that a serious C/C++ programmer could look at that specification and not see the issue before blindly committing it to code today. I suppose it could happen. OpenSSL (which everyone else here is crying about as an example) is also over 20 years old. > And still no one cares. It takes some competence to stop using C, but it's easier to simply shout at those who point out the obvious. Well imagine trying to rewrite the Linux kernel today in a memory safe language, without losing any support for any of the current target architectures. Or NetBSD even more so for that matter. Nobody has convinced me it could be done, and as of yet, it hasn't been. Throwing away C and C++ for good is fine - if you don't want to do much in the way right now of embedded programming, or working with sophisticated games engines (eg. UE4), just for fun. If you're not confident of the quality of the code, then maybe don't deliver it to for all and sundry saying its fit for purpose. And if you are confident, then check it again. That's all I'm saying.
- 8y ago

ken 8y ago

And yet, look at all the billions (trillions?) of lines of code in the world which do not have a horrible security flaw. Heartbleed is notable because of its rarity. OpenSSL is over 500,000 lines of C, written by 500 contributors, and somehow it generally works pretty well. Maybe the phrase "a decent programmer would never" unfairly assigns blame to an individual's skill, but I think it would be fair to say that the programmers who designed and implemented these bugs were not doing decent work on the day that they made these mistakes. If our standards for C programmers don't include bounds checking of array access, what exactly do they include?

zozbot123 8y ago
The whole problem is that you only need one mistake in all those billions/trillions of LOC's, and your systems get 0wned. I'm pretty sure that "our standards for C programmers" don't include "programmer is guaranteed not to make any mistake, EVAR", whereas that's an entirely appropriate standard for automated, language-based security.
- nineteen999 8y ago
  See the related article posted from Microsoft today; Microsoft: 70 percent of all security bugs are memory safety issues https://news.ycombinator.com/item?id=19138602 If we could get rid of that 70% that would be great, but it still leaves programmers doing other stupid shit in the other 30% of cases.