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.)

In reply to Re^8: Can't use an undefined value as a HASH reference by Monk::Thomas
in thread Can't use an undefined value as a HASH reference by Anonymous Monk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.