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
