John Sullivan wrote: >>> >>> We don't check against a hard limit but TOT will no longer crash or >>> overwrite memory (try it). We now detect the allocation failure. But >>> it might be good to also set a hard upper limit on rowspans. >>> >>> Regards, >>> Maciej >> Wearing belt AND suspenders never hurts, right? Until there's a >> performance hit, I don't see that you can have too many checks. > > Any time you put in a hard limit for something, you run the risk of > running into a legitimate case where the hard limit is exceeded. So > it's not just a "belt and suspenders" issue -- there is a real > downside for this kind of change. > > Absolutely! Whatever limit you choose, someone will want more. I didn't word what I said very well. >> >> A lot of people seem to be interpreting it as a security hole in spite >> of the fact that the report says Safari will "crash, and or execute >> arbitrary code." I suppose that "and or" maybe gives them an out, but do >> they truly believe that _every_ crashing bug is exploitable? > > They aren't thinking at all, is my guess. One person somewhere found a > reproducible crash, and somehow got the idea that it was potentially a > security risk, and he wrote that down somewhere, and everyone else is > just repeating it without thinking. > > John Well except that the report is from a "company", although of course it could be just the one guy. People are definitely giving it more credence than it deserves.
_______________________________________________ webkit-dev mailing list [email protected] http://www.opendarwin.org/mailman/listinfo/webkit-dev
