At 23:40 16/12/2006, Ilia Alshanetsky wrote:
You're not helping them, just making assumptions about how their
code should work and making them adhere to them.
Yes, and this is helping. Every language does that. Saying "you
can't make 100% work exactly as I wanted without any effort, so
entire thing isn't even worth discussing" is a road nowhere.
There's a lot of places it would be helpful, and there's a lot of
places it won't - and that's ok.
I am saying that you should not try to outsmart the developer because
you assume you know best.
Ilia,
Why are we outsmarting developers? Security bugs are out there, in
fact in web apps they're pretty much a plague (irregardless of the
language). Does it mean that some developers aren't smart and many
are not properly informed? Absolutely YES - that's the world we live
in... Given that, and the likelihood it'd only get worse (more and
more people are programming the web with less and less training) -
whatever we can provide in the direction of creating better apps can help.
My 2c on this piece is that tainting can be a nice helper tool to
reduce the likelihood of security problems in your code. Nothing
more and nothing less.
I too fear the possibility of tainting becoming the new
safe_mode. "Outsource your security to PHP, it'll take care of
it". But I think there's a way of both designing and pitching
tainting so that we avoid this false perception. If we pitch
tainting as a development-time only tool the points out a certain
class of security mistakes, and is by no means an invisible magnetic
shield that actually protects you from them - then I think it can be
quite useful.
As such, I would consider:
- Saying tainting should not be enabled in production (avoid the
false sense of security people might have if they turn on tainting in
production).
- Not necessarily the fastest possible implementation, since it'd be
used for development purposes only.
- Consider making this a compile time option with significant
overhead and a big DO NOT ENABLE IN PRODUCTION, so that people have
an even clearer idea they shouldn't rely on it to find their bugs,
and that in fact it's just a helper tool, not unlike a strong IDE.
We could possibly even come up with a new name other than tainting so
that there is not prior perception as to what this feature is
supposed or not supposed to do.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
