Hello,
I hereby ask for access to security related bugs with the security flag set.
I was pointed here by Pierre Joye to formally request this.
Thanks in advance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I am fine with this approach, with 2 caveats:
- If you actually do want to make two traits use the same property, it
looks like the answer here is "Either have no property and demand the
existence of an accessor that returns by reference, or you can't write
E_NOTICE-safe code". Is that true?
Note that this is already possible by setting post_max_size to 0M. Was
useful prior to the APC upload hooks for writing progress bars.
2010/12/16 Ángel González
> Gustavo Lopes wrote:
>
> > I've committed to trunk the patch with the name of the ini option changed
> > from disable_post_data_proce
Gustavo Lopes wrote:
> I've committed to trunk the patch with the name of the ini option changed
> from disable_post_data_processing to enable_post_data_reading.
Pierre Joye wrote:
> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this co
Gustavo Lopes wrote:
> I know you're responding to Pierre's proposed addition of a way to
> disable POST data handling altogether possibly via an ini option, but
> since the objection also applies to the ini option I've added to
> trunk, I'd like to address it.
>
> Yes, it sucks that the option can
2010/12/16 Stefan Marr :
> Hi:
>
> From my point of view the right thing to do with regard to properties is
> defined in the test cases below.
>
> The rational behind providing this semantics is based on the fact that PHP
> allows to define properties dynamically anyway, so there is no way around
On Thu, Dec 16, 2010 at 6:09 PM, Gustavo Lopes wrote:
> In short, I don't think the possibility of a future implementation of more
> high level mechanisms should preclude the existence of low level ones such
> as the proposed and committed enable_post_data_processing, as the low level
> ones, bei
On 2010-12-16, Stefan Marr wrote:
> From my point of view the right thing to do with regard to properties
> is defined in the test cases below.
>
> The rational behind providing this semantics is based on the fact that
> PHP allows to define properties dynamically anyway, so there is no way
> arou
Hi!
ICU btw has some global stuff too.
I think it's clear that having any global stuff does not necessarily make
the code thread-unsafe.
Oh, this one does. It's not crash-unsafe, just weird-bugs-unsafe.
It's my only guess - this is because a correct sorting of words in some
languages requi
On Thu, 16 Dec 2010 14:53:08 -, Matthew Weier O'Phinney
wrote:
On 2010-12-16, Pierre Joye wrote:
I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You should also keep in mind that even if it is
I like it,
additionally if you want to prevent conflicts from the start you can
always go and define prefixed property names like below and use a getter to
access them conveniently.
trait Foo
{
private $Foo_prop;
public function getProp()
{
return $this->Foo_prop;
Am 16.12.2010 16:25, schrieb Stefan Marr:
> From my point of view the right thing to do with regard to
> properties is defined in the test cases below.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://
Hi:
From my point of view the right thing to do with regard to properties is
defined in the test cases below.
The rational behind providing this semantics is based on the fact that PHP
allows to define properties dynamically anyway, so there is no way around
properties.
However, there should b
I think you over react due to our past mistakes. What I'm trying to explain
is exactly what you want. Efficienty without cinfusionsconfusions, ugly
hacks or features duplication.
And that's what I would like to discuss here instead if just doing it, for
the sake of doing it.
On 16 Dec 2010 15:53,
On 2010-12-16, Pierre Joye wrote:
> On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
> wrote:
>> On 2010-12-16, Pierre Joye wrote:
> > The only way I can see such an action being "sensible" is if it's also
> > runtime configurable (i.e., via ini_set()) - otherwise I foresee a ton
> > of i
On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
wrote:
> On 2010-12-16, Pierre Joye wrote:
>> There are a lot of values to disable POST completely. That's also why
>> thinking the option you are proposing while keeping in mind the whole
>> picture makes sense.
>>
>> There are different e
On 2010-12-16, Pierre Joye wrote:
> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> introduced, like disabli
On Thu, Dec 16, 2010 at 3:08 PM, Pierre Joye wrote:
> doing something badly designed only because we can do it is a very bad
> idea.
>
>
you didn't said that this patch is badly designed, you just said, that with
putting some other ideas together we could come up with a more better
solution.
if y
doing something badly designed only because we can do it is a very bad idea.
On Thu, Dec 16, 2010 at 2:51 PM, Ferenc Kovacs wrote:
> http://en.wikipedia.org/wiki/Nirvana_fallacy
> If you think that there is a better alternative, please write an RFC and or
> a patch, but I don't think that we sho
On Thu, Dec 16, 2010 at 2:16 PM, Pierre Joye wrote:
> There are a lot of values to disable POST completely. That's also why
> thinking the option you are proposing while keeping in mind the whole
> picture makes sense.
>
> There are different existing modes and one or two new modes (to be
> intro
There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.
There are different existing modes and one or two new modes (to be
introduced, like disabling POST). Having a clean way to choose which
m
On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye
wrote:
As I said in IRC, I see no value in having an option that disables
accessing POST data completely (i.e. the behavior of
enable_post_data_reading=Off + disallowing reading it through
php://input).
With enable_post_data_reading=Off, the only w
On Thu, Dec 16, 2010 at 1:47 PM, Pierre Joye wrote:
> hi,
>
> On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs wrote:
>
> > So currently we didn't talk about security measures, but performance
> gains:
> > If somebody wants to write a script, which handles big file uploads, but
> > only writes it
hi,
On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs wrote:
> So currently we didn't talk about security measures, but performance gains:
> If somebody wants to write a script, which handles big file uploads, but
> only writes it to somewhere (to file, or another stream), then currently you
> have
On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye wrote:
> hi,
>
> The more I look at this option the more I think it is confusing. I'm
> not sure the gain is worth this confusion either. However I would
> prefer to bring back a proposal we had a couple of years ago, to
> totally disable post data. Wh
hi,
The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this confusion either. However I would
prefer to bring back a proposal we had a couple of years ago, to
totally disable post data. When disabled, the POST data will be
totally ignored, no matter if
The PHP development team would like to announce the immediate
availability of PHP 5.2.16. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
This release focuses on addressing a regression in open_basedir
implementation introduced in 5.2.1
"Stas Malyshev" wrote
> Hi!
>
>> An example of non-thread safe is gettext it relies on the locale which is
>> per process and not per-thread.
>>
>> PHP itself at the core is thread safe. As Johannes said most common
>> modules are too.
>
> ICU btw has some global stuff too.
I think it's clear t
> "Scott MacVicar" wrote in message:
> >
> >
> > Do you think any locking function is implemented in openssl php
> > extension?
> >
> In PHP a SSL_CTX is per thread and is not shared across other threads so
> it isn't an issue. We don't need to implement any openssl locking
> functions.
It doe
Hi!
An example of non-thread safe is gettext it relies on the locale which is per
process and not per-thread.
PHP itself at the core is thread safe. As Johannes said most common modules are
too.
ICU btw has some global stuff too. It's actually worse as it has one
global which is set depend
On Dec 16, 2010, at 12:28 AM, jvlad wrote:
>>> No. Php if we talk about php with all its extensions is not threadsafe
>>> at
>>> all. Many of the extensions allocate static data and inherently
>>> non-thread-safe.
>>
>> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
>> so
>> No. Php if we talk about php with all its extensions is not threadsafe
>> at
>> all. Many of the extensions allocate static data and inherently
>> non-thread-safe.
>
> PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
> some extensions might not be thread safe, but basically
32 matches
Mail list logo
