in reply to Re^6: Can't use an undefined value as a HASH reference
in thread Can't use an undefined value as a HASH reference

It is simply an example in how one could apply the robustness principle to this particular case.

Sorry, but that is garbage; as I said, a strawman.

The robustness principle does not suggest being stupid; and I reject all of your attempts to imply that it does.

I do not recognise any of your "examples" of stupidity as valid examples of applying the Robustness Principle as it is intended; or as it is correctly used.

The rest of your post reads as a hastily concocted justifiction by someone who knows his bluff has been called; but continues to think that he can get away with it if he can throw enough other strawmen, misdirection, smoke screens and specious arguments into the mix. You can't.

The Robustness Principle simply means that you don't die in the face of unexpected or incorrect input; you log a warning, ignore it; and then carry on doing so until you either get good input or EOF or timeout. And that's it. It could equally have been termed the "Don't be fragile or pedantic or a prima donna" Principle.

It does not mean that you attempt to fix bad input; nor fail to apply common sense; nor do any of the other stupid actions you claim are attributable to it. They aren't.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
  • Comment on Re^7: Can't use an undefined value as a HASH reference

Replies are listed 'Best First'.
Re^8: Can't use an undefined value as a HASH reference
by Monk::Thomas (Friar) on Aug 26, 2015 at 17:08 UTC

    You said: The Robustness Principle simply means that you don't die in the face of unexpected or incorrect input; you log a warning, ignore it; and then carry on doing so until you either get good input or EOF or timeout. And that's it. It could equally have been termed the "Don't be fragile or pedantic or a prima donna" Principle.

    RFC 761 says: 2.10: TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. (It then continues with part 3 "FUNCTIONAL SPECIFICATION".)

    I do not see a reference on how to handle data that falls outside of what's deemed 'liberal' and acceptable. Additionally you seem to be reading something into this posting that is not there - I did not say anything about a particular way to react to an error (e.g. terminate). What I did say was to refuse invalid input. I did not say how to refuse it. (I even gave an example on how to be more forgiving and prevent die() in Re^4: Can't use an undefined value as a HASH reference!)

    But maybe I misunderstood the meaning of these few words. In an attempt to rectify that I was looking around a bit and stumbled upon:

    The Robustness Principle was formulated in an Internet of cooperators. The world has changed a lot since then. Everything, even services that you may think you control, is suspect. It's not just user input that needs to be checked—attackers can potentially include arbitrary data in DNS (Domain Name System) results, database query results, HTTP reply codes, you name it.
    [...]
    The atmosphere of the Internet has changed so much that the Robustness Principle has to be severely reinterpreted. Being liberal in what you accept can contribute to security problems. Sometimes interoperability and security are at odds with each other. In today's climate they are both essential. Some balance must be drawn.
    -- http://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltext

    This is precisely the point I'm trying to make. There must be a line where you say enough is enough and refuse to process the provided data any further. (Again: I do not say how to refuse it.) To me it seems like we favored interoperability way to much and now we're paying the price. Adversaries deliberately exploit corner cases. Being more conservative in what to accept would NOT magically make these exploits go away. But it would reduce the attack surface because there are less conditions to consider. Less cases -> less code -> less bugs -> less exploits. (Hopefully.)

[reply]

      And now you have strayed so far from where this started it would be meaningless to continue to respond to you.

      Nothing in the OP suggests that he is dealing with data received from untrusted sources. NOTHING!

      And everything you have said that is founded upon that premise is meaningless in the context of the OP and my response.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
      I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!
[reply]

        I find it quite strange how you reply to something that is not part of my postings. I did not use or cite the word untrusted anywhere in this thread. In the posting you replied to I was specifically talking about and referring to handling invalid input. And the OP did indeed have a problem with the input that was provided -> Re^4: Can't use an undefined value as a HASH reference.

        So basically we're still OnTopic: The code does not handle the provided input very well and fails to properly react to it. As a solution one could choose to either be more lenient in what to accept or one could verify the input more closely and refuse to process it. Both have their merits and they have been discussed extensively now.

        (Addendum: I did refer to attackers, but in this case Anonymous was accidentally both Attacker and Target.)
[reply]

In Section Seekers of Perl Wisdom