On Sun, 28 Oct 2012, Tom Bishop, Wenlin Institute wrote: > A naive PCRE user only wants to know whether a file begins with a > particular character sequence, for example, "#!/bin/bash". Not caring > whether the file is valid UTF-32 and not having read the documentation > very carefully, this programmer uses the flag PCRE_NO_UTF32_CHECK so > that the program will run faster (or maybe just having copy-pasted it > from somewhere). PCRE says the file matches "#!/bin/bash", so the > program executes the file as a bash script, causing a nuclear power > plant to explode.
With respect, I think this is a bit drastic. Anybody writing a program where the consequences of failure are so catastrophic *should* care whether the file is valid UTF, should read the documentation, and shouldn't just copy-paste. I know people are stupid. Are they really *that* stupid? Should we not implement PCRE_NO_UTFx_CHECK at all? Using it incorrectly can cause crashes and problems in all modes. I am happy to beef up the warnings in the docs. > Do any of you happen to be on the mailing list for libcurl? A recent > discussion is relevant. The subject line is "The Most Dangerous Code > in the World". Due to widespread misunderstanding of the API, many > programs using libcurl have made this error: "setting > CURLOPT_SSL_VERIFYHOST to TRUE, will result in the SSL connection > being insecure against a man-in-the-middle attacker". Sounds harmless, > right? The word "insecure" doesn't sound harmless to me! > Given an option named CURLOPT_SSL_VERIFYHOST, wouldn't TRUE be > better than FALSE? In fact it's supposed to be a three valued option, > not boolean, and the value "1" is dangerous. It is regretful that the C language does not have proper boolean values/variables, but instead subverts ints. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
