> ... ESPECIALLY since userland implementation is so trivial. "Trivial" for most users means "copy-paste an unmaintained class library you found somewhere" so you haven't solved the problem. Unless something comes from one of the few trusted security extensions or from a top framework, it's doubtful it'll be thoroughly reviewed and/or correctly implemented.
I think security measures belong in the preprocessor if possible. If they are known to be useful, yet rejected only because they're "trivial" -- despite not being commonly available to the majority of PHP developers -- you are failing the community. On the other hand, if they are known to be useful, yet rejected because they're "complex, requiring too many config options, new classes/functions, core documentation, AND user education to write companion logic in userland" then I think that's better reasoning. And that's *clearly* the case here. This is not a simple implementation; it requires flexible control from userland and some delicate app logic to interact with the user, and the language can't do the last part AFAICS. As sketched out so far, it is outright harmful. I could publish a post now about the vulnerability it creates, where sniffing a session allows you to force an elevated login, from which you can sniff credentials. (Maybe my first vuln note was tl;dr but please consider this.) > The core of the problem is education, not lack of tools by the side > of the language. And that's where the focus should be. How do we do > it? I don't know. Blog posts? PHP manual? Conferences? Maybe. The first round of objections showed that senior developers *on Internals* didn't understand how PHP session regeneration works! How do you solve that? If the language offered features like this in the first place, PHP users would have known about for years. The fact that it wasn't grokked here reveals that no matter how "trivial' it seems, most people aren't doing it (as yohgaki noted) and not because they understand the consequences, they just don't get it at all. Again, if it were simple to implement and didn't have unintended security consequences of its own, the fact that the sharpest users don't totally get it would *prove* that it should be left to the internals team. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
