We shouldn't neuter the language because some stupid people might do stupid people. Use appropriate error handling, not inappropriate error handling because it might catch someone out who has a poorly configured server.
On 16 July 2012 14:40, Alex Aulbach <alex.aulb...@gmail.com> wrote: > Hi Anthony, > > Sorry, I'm really off topic here. What I suggest here is just to think > about new ways to make PHP more secure - and I think how to work with > errors is an important thing in this case. > It's here, because the password-rfc is just a good example for > security. :) It's not critic to the RFC, which I like. > > > 2012/7/16 Anthony Ferrara <ircmax...@gmail.com>: >>> - we never know in which context the program will run. And good >>> security means, thait it shouldn't care, in which context it runs. >> >> Could you explain what you mean by context here? I'm not following... > > Hm. I mean configuration, or 32 vs. 64 bit. Someone could turn > display_errors off and complains seeingf only a blank page. The other > can complain about seeing stupid password-function-warnings in his > browser, because he turned it on. Someone could have installed an own > error-handler which will run crazy with those errors. Someone > complains, that the methods are not compiled in his version of PHP. > And so on. We don't know the context. Sometimes it could be more > secure to send errors to the users, sometimes not. Sometimes it's a > real failure, sometimes we can ignore it. > > But here and now our focus is security. The question is: Which is the > most secure method to do something without knowing the context. I > think this can be decided in most times very well. > >>> - everything, which can go wrong will go wrong (Murphy); if there is >>> any chance to make it wrong, there will be someone, which make it >>> wrong. (and in this case they will point to PHP: "see, I have said it >>> is unsecure..." :) ). >>> - in security context this means: The hashe1s will be stolen/we can >>> login without password etc. >>> - No documentation or any other thing can prevent that >> >> >> You can not make something idiot proof. If you try, the universe will just >> invent better idiots. > > :) Yeah. But we won't make it fool proof, we want to make it secure. > Big difference, because this can be defined in some cases very well, > even if you don't know the context. > > And again: We are off topic here; those are things, which cannot be > fixed by some methods in PHP. But for me it's obvious to speak about > it, when I speak about security. > > >>> - So we need to do everything, which is possible to avoid it. The best >>> thing would be, that we can guarantee, that it is not possible. >> >> If that was the case, there would be no PHP or any other language for that >> matter. You can't stop people from being stupid. > > We cannot prevent stupidity, but we can prevent the impacts. Like with > my printer example: If the printer don't know what happend, he will > force to look into every printer-tray, before it will print again, > just because it is the most secure way. > > I think, this should be default for PHP, too (but it's just my > opinion). Only if we know what we're doing, we can handle the error. > It should be something, which must be programmed, not configured. This > will avoid context. > > >> What you can do however is >> make the documentation and implementation so bloody easy to use that *I >> didn't know* becomes the only sane excuse... > > Good docs is a part of good security. In this case it's also concepts > of handling errors. And much other stuff. > > Again: This is off-topic. The RFC is very fine, it's a good work, I > like it! Really, I do! :) > > But for me - as PHP-developer - it's like renewing all doors of a > house with newest technique, but forgetting the windows. :) Security > is a concept. My suggestions aren't perfect. Just want to talk about > it; I think those concepts need time. > > -- > Alex Aulbach > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Andrew Faulds (AJF) http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
