On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling <rquadl...@gmail.com>wrote:
> 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 > bump -- Ferenc Kovács @Tyr43l - http://tyrael.hu
