Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58928
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKUjMCW+j=fL4oS1+cQ6QMy1ZGPK-sy=af7gnL2NJq86_yh4Vg@mail.gmail.com>
References: <CAH-PCH5jJ1ctJy6kZcyMLxSKyJs=+pA8ivB89MEzQtKfJWiHMQ@mail.gmail.com>
	<CAKUjMCW+j=fL4oS1+cQ6QMy1ZGPK-sy=af7gnL2NJq86_yh4Vg@mail.gmail.com>
Date: Wed, 14 Mar 2012 18:09:54 +0100
Message-ID: <CAH-PCH7WKbvPPU1N0uuFB416Sf_tpG+w++kRgdRgnZRexG=PJw@mail.gmail.com>
To: RQuadling@gmail.com
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10c8995025b304bb370b5e
Subject: Re: [PHP-DEV] set the PHP_INI_ENTRY_* values the same as for php.ini-production
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7b10c8995025b304bb370b5e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling <rquadling@gmail.com>wro=
te:

> On 23 July 2011 23:29, Ferenc Kovacs <tyra3l@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

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7b10c8995025b304bb370b5e--