On 23 July 2011 23:29, Ferenc Kovacs <tyr...@gmail.com> wrote: > hi. > > We had a discussion about the magic_quotes removal that it is weird > that even though that mq was deprecated in 5.3, we still have/had that > enabled by default (if you didn't set it from the command line or > through a php.ini, the default value which is set from the source by > the PHP_INI_ENTRY_* macros). > I would propose that the defaul values(PHP_INI_ENTRY_*) and the > php.ini-production should be keep in sync as much as possible. > for one thing, this would be less confusing (what do we mean by > default? PHP_INI_ENTRY_* or the php.ini? why are they different? > etc.), the second thing would be the principle of the fail-secure > principle: usually the production settings are more secure and less > verbose(display_errors for example). > what do you think? > of course, if this keeps traction, a proper RFC would be needed, but > for now, I'm just throwing ideas.
My preference would be to have the defaults be for a production environment. So, if you do absolutely nothing except copy php.exe and a few DLLs, (no ini file), the defaults work to an agreed safe standard. I would envisage that this standard changes over time if weaknesses are found and exploited (I'm not saying there are any). I would then like 1 ini file that only contains specific changes to the defaults for a development environment. I would also like 1 ini file that exactly matches the defaults and that this file must be maintained in line with the internal macros. It would serve as a one stop place to see all the settings as they are defined by the PHP group and could indicate the preference for production and development. So, for a truly lazy developer, it is 1 ini file rename (activate the development environment) and only the agreed entries are amended from the production safe environment, rather than overriding any defaults from the macros, which could have changed and are now out of sync with the INI file. Of course, what is considered safe is for you guys to decide, but with so many settings in the INI files and, as we have seen, disagreement between the internal macros, a little consensus should go a long way to be able to help ISPs and shared hosters have a more uniform standard. Maybe, and this is right of the top of my head, if PHP is installed for a production environment with no INI file, or if an ini file doesn't alter any of the core settings (maybe a separation of INI files for core and extensions?), it could be labelled/considered as a virgin PHP install. Something which could be marketed / advertised. Essentially, the PHP Group agree that for a production environment, these are the settings that are the safest to use. If there are considerations that need to be made for shared hosters, then maybe some mechanism to set these appropriately. So, for a user coming to an ISP and looking at hosting, they can see "We use Virgin PHP Settings" or something like that and know that they won't be different to a documented "standard". Add this labelling to the phpinfo() page and it makes things very very clear what is in play. Richard. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
