Re: [PHP-DEV] Remove $age parameter of curl_version()

[Sara Golemon]

On Wed, May 1, 2019 at 12:18 PM Christoph M. Becker 
wrote:

>
> curl_version()[1] (of ext/curl) makes curl_version_info()[2] (of
> libcurl) available to PHP userland.  The latter requires to pass an age
> argument which usually is CURLVERSION_NOW, so that the information
> returned by the runtime matches the declarations used during compile
> time.  For C programs it is simply necessary to pass this information,
> and it might make sense to pass something else than CURLVERSION_NOW, but
> the PHP wrapper assumes that the return value of curl_version_info()
> matches the compile time declarations anyway, so passing anything else
> might give bad results.
>
> Wow... yeah. That's an example of being far too idiomatic with the
bindings. I didn't even know we accepted that arg.  Kill it with fire.

-Sara

Re: [PHP-DEV] Revive Number Format Separator RFC

[Bishop Bettini]

On Wed, May 1, 2019 at 5:42 AM Thomas Punt  wrote:

> Hi!
>
> > On Wed, May 01, 2019 at 01:13 AM Bishop Bettini  wrote:
> > > On Tue, Apr 30, 2019, 19:14 Theodore Brown  wrote:
> > >
> > > On Tue, Apr 30, 2019 at 3:59 PM Bishop Bettini  wrote:
> > >
> > > > Excellent. I hope we can make the case this time. Please
> > > > request Wiki karma [1], and we'll iterate on it there.
> > >
> > > I was granted karma, and published an initial RFC draft:
> > > https://wiki.php.net/rfc/numeric_literal_separator.
> > >
> > > I would greatly appreciate help with the implementation, since I
> > > don't have much experience with C and haven't contributed to PHP
> before.
> > >
> > > Also let me know if you have any ideas for improving the RFC.
> > >
> >
> > I am happy to help with these. Let us take the RFC refinement and
> > implementation details conversation off-list. Then come back when
> prepared
> > to present for discussion.
>
> I would think that pretty much the whole of the original implementation[1]
> should
> be reusable (maybe some merge conflicts to fix only). But anyway, I can
> offer some
> support with the implementation, if needed.
>

Great, thanks Tom. Theodore and I are polishing the RFC, then will tackle
the implementation. Besides the necessary merge fixes, are there any
changes/improvements you specifically want to make in the new proposed
implementation?

[PHP-DEV] Re: Issuing CVEs for PHP

[Pierre Joye]

Hi Stas

Excellent!!

thanks you for taking care of this

best,
Pierre

On Mon, Apr 29, 2019, 10:51 AM Stanislav Malyshev 
wrote:

> Hi!
>
> I have set up PHP as CNA (CVE Identifiers authority) with MITRE. That
> means that we will be assigning our own CVEs from now on. The process in
> broad strokes works like this:
>
> 1. We request a block of numbers
> 2. When we have security bug, we use one of the numbers in the block
> 3. We create CVE descriptions and commit them to the cvelist repo
>
> Much more detailed documentation on how it is done is here:
> https://wiki.php.net/cve
>
> So far I am the only one who is registered to commit CVE descriptions to
> MITRE upstream repo, but if somebody wants to do it too, I'm sure it can
> be arranged.
> Note that you can assign CVE to a bug not yet fixed or published in the
> open. Please use this capability responsibly and keep the tracking in
> https://wiki.php.net/cve . If you are not familiar with the process or
> don't want to bother, just put "needed" as CVE number and it will be
> taken care of. Please not enter the bug details into the public repo
> before the fix is released.
>
> If you have any questions about this, please ask me.
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] Remove $age parameter of curl_version()

[Nikita Popov]

On Wed, May 1, 2019 at 7:19 PM Christoph M. Becker 
wrote:

> Hi,
>
> curl_version()[1] (of ext/curl) makes curl_version_info()[2] (of
> libcurl) available to PHP userland.  The latter requires to pass an age
> argument which usually is CURLVERSION_NOW, so that the information
> returned by the runtime matches the declarations used during compile
> time.  For C programs it is simply necessary to pass this information,
> and it might make sense to pass something else than CURLVERSION_NOW, but
> the PHP wrapper assumes that the return value of curl_version_info()
> matches the compile time declarations anyway, so passing anything else
> might give bad results.
>
> Therefore I suggest to remove this parameter in the long run altogether.
>  For PHP 7.4 I suggest to deprecate using the parameter, and also to
> ignore anything that is not CURLVERSION_NOW, and to raise a warning in
> this case.  I.e. something like the following behavior:
>
>// okay
>   curl_version();
>
>   // E_DEPRECATED: passing an argument is deprecated
>   curl_version(CURLVERSION_NOW);
>
>   // E_WARNING: argument ignored
>   curl_version($not_curlversion_now);
>
> Thoughts?  Do I overlook something important?
>

Sounds good to me.

Nikita

Re: [PHP-DEV] Remove $age parameter of curl_version()

[Bishop Bettini]

On Wed, May 1, 2019 at 1:18 PM Christoph M. Becker 
wrote:

>
> curl_version()[1] (of ext/curl) makes curl_version_info()[2] (of
> libcurl) available to PHP userland.  The latter requires to pass an age
> argument which usually is CURLVERSION_NOW, so that the information
> returned by the runtime matches the declarations used during compile
> time.  For C programs it is simply necessary to pass this information,
> and it might make sense to pass something else than CURLVERSION_NOW, but
> the PHP wrapper assumes that the return value of curl_version_info()
> matches the compile time declarations anyway, so passing anything else
> might give bad results.
>

It looks like the ext/curl binding [1] handles run-time age values that
differ from compile-time, as it makes checks for if (d->age). Am I missing
something?


> Therefore I suggest to remove this parameter in the long run altogether.
>  For PHP 7.4 I suggest to deprecate using the parameter, and also to
> ignore anything that is not CURLVERSION_NOW, and to raise a warning in
> this case.  I.e. something like the following behavior:
>
>// okay
>   curl_version();
>
>   // E_DEPRECATED: passing an argument is deprecated
>   curl_version(CURLVERSION_NOW);
>
>   // E_WARNING: argument ignored
>   curl_version($not_curlversion_now);
>
> Thoughts?  Do I overlook something important?
>

Well, what about:

if (false === curl_version(3)) {
throw new \Exception('Please rebuild PHP with curl at least
version 7.16.1');
}

Here the developer has used age as a proxy to a major release point of
curl, as opposed to say:

if (version_compare(curl_version()['version'], '7.16.1', '<') { throw new
Exception...; }

[1]: https://github.com/php/php-src/blob/master/ext/curl/interface.c#L1824

[PHP-DEV] Remove $age parameter of curl_version()

[Christoph M. Becker]

Hi,

curl_version()[1] (of ext/curl) makes curl_version_info()[2] (of
libcurl) available to PHP userland.  The latter requires to pass an age
argument which usually is CURLVERSION_NOW, so that the information
returned by the runtime matches the declarations used during compile
time.  For C programs it is simply necessary to pass this information,
and it might make sense to pass something else than CURLVERSION_NOW, but
the PHP wrapper assumes that the return value of curl_version_info()
matches the compile time declarations anyway, so passing anything else
might give bad results.

Therefore I suggest to remove this parameter in the long run altogether.
 For PHP 7.4 I suggest to deprecate using the parameter, and also to
ignore anything that is not CURLVERSION_NOW, and to raise a warning in
this case.  I.e. something like the following behavior:

   // okay
  curl_version();

  // E_DEPRECATED: passing an argument is deprecated
  curl_version(CURLVERSION_NOW);

  // E_WARNING: argument ignored
  curl_version($not_curlversion_now);

Thoughts?  Do I overlook something important?

[1] 
[2] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[M. W. Moe]

Hello,

the _convert_to_string return signature should be changed i.e returning a
status;
hence, accordingly to this status, within a context caller, you may decide
to trigger
an exception  or not ; that's not the role of a conversion function to
handle
those concerns; thus the realm is wider than what it is sold here.

Cheers!

On Wed, May 1, 2019 at 7:53 AM Bishop Bettini  wrote:

> On Wed, May 1, 2019 at 7:36 AM Dan Ackroyd  wrote:
>
> > On Wed, 1 May 2019 at 03:54, Bishop Bettini  wrote:
> > >
> > > But I'd still think this would be a "many eyes needed" kind of PR,
> > especially from extension maintainers.
> >
> > Hypothetically, what should these extension maintainers be looking for?
> >
> > Other than "Mmm-hmm. Mmm-HMM. I know some of these words!" ?
> >
>
> Indeed. I'm by no means an expert, but here's what I did for phar and imap
> extensions. I read the RFC and "got to know" the new helper methods for
> resolving stringy content. I then looked at the PR for all changes to phar
> and imap, verifying that I understood the changes Nikita made. Then I went
> to master and PHP-7.4 branches and looked for any other cases that might
> need to be changed, and while there took mental note of improvement
> opportunities should this RFC pass.
>
> When I was in there, I was basically looking for "convert_to_string" (and
> friends) and if I found any that Nikita hadn't already found, replacing
> those with one of the new helpers and making sure I understood the choice
> Nikita made and commenting if I disagreed. I was also looking for any case
> where the conversion touched data that persisted and made sure it wasn't
> going to get trashed by a bad conversion.
>
> I also went through code outside phar and imap looking for things I didn't
> understand or surprised me or didn't look correct. Suffice to say, there's
> a lot of code to look through. Some code surprised me, like that the (new
> DateInterval(...))->{$badStr} unhappy path didn't adhere to the
> has_property contract, so that was a bugfix Nikita made as an artifact of
> this sweep, which is great and I think emblematic of the reason to get more
> eyes on this: might be more of those lurking in the code base.
>

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Bishop Bettini]

On Wed, May 1, 2019 at 7:36 AM Dan Ackroyd  wrote:

> On Wed, 1 May 2019 at 03:54, Bishop Bettini  wrote:
> >
> > But I'd still think this would be a "many eyes needed" kind of PR,
> especially from extension maintainers.
>
> Hypothetically, what should these extension maintainers be looking for?
>
> Other than "Mmm-hmm. Mmm-HMM. I know some of these words!" ?
>

Indeed. I'm by no means an expert, but here's what I did for phar and imap
extensions. I read the RFC and "got to know" the new helper methods for
resolving stringy content. I then looked at the PR for all changes to phar
and imap, verifying that I understood the changes Nikita made. Then I went
to master and PHP-7.4 branches and looked for any other cases that might
need to be changed, and while there took mental note of improvement
opportunities should this RFC pass.

When I was in there, I was basically looking for "convert_to_string" (and
friends) and if I found any that Nikita hadn't already found, replacing
those with one of the new helpers and making sure I understood the choice
Nikita made and commenting if I disagreed. I was also looking for any case
where the conversion touched data that persisted and made sure it wasn't
going to get trashed by a bad conversion.

I also went through code outside phar and imap looking for things I didn't
understand or surprised me or didn't look correct. Suffice to say, there's
a lot of code to look through. Some code surprised me, like that the (new
DateInterval(...))->{$badStr} unhappy path didn't adhere to the
has_property contract, so that was a bugfix Nikita made as an artifact of
this sweep, which is great and I think emblematic of the reason to get more
eyes on this: might be more of those lurking in the code base.

Re: [PHP-DEV] Re: [VOTE] Arrow functions / short closures

[Bishop Bettini]

On Wed, May 1, 2019 at 4:42 AM Nikita Popov  wrote:

> On Wed, Apr 17, 2019 at 12:58 PM Nikita Popov 
> wrote:
>
> > Hi internals,
> >
> > I've opened voting on the arrow functions RFC. The vote closes May 1st.
> >
> > https://wiki.php.net/rfc/arrow_functions_v2#vote
> >
> > The RFC uses the fn($x, $y) => $x*$y syntax as originally proposed.
> >
>
> I'm pleased to say that the arrow functions RFC has been accepted with 51
> votes in favor and 8 against.
>

Nikita, Levi, and Bob: thank you! I appreciate your hard-work over these
many years.

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Dan Ackroyd]

On Wed, 1 May 2019 at 03:54, Bishop Bettini  wrote:
>
> But I'd still think this would be a "many eyes needed" kind of PR, especially 
> from extension maintainers.

Hypothetically, what should these extension maintainers be looking for?

Other than "Mmm-hmm. Mmm-HMM. I know some of these words!" ?

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Revive Number Format Separator RFC

[Thomas Punt]

Hi!

> On Wed, May 01, 2019 at 01:13 AM Bishop Bettini  wrote:
> > On Tue, Apr 30, 2019, 19:14 Theodore Brown  >
> > On Tue, Apr 30, 2019 at 3:59 PM Bishop Bettini  wrote:
> >
> > > Excellent. I hope we can make the case this time. Please
> > > request Wiki karma [1], and we'll iterate on it there.
> >
> > I was granted karma, and published an initial RFC draft:
> > https://wiki.php.net/rfc/numeric_literal_separator.
> >
> > I would greatly appreciate help with the implementation, since I
> > don't have much experience with C and haven't contributed to PHP before.
> >
> > Also let me know if you have any ideas for improving the RFC.
> >
>
> I am happy to help with these. Let us take the RFC refinement and
> implementation details conversation off-list. Then come back when prepared
> to present for discussion.

I would think that pretty much the whole of the original implementation[1] 
should
be reusable (maybe some merge conflicts to fix only). But anyway, I can offer 
some
support with the implementation, if needed.

Thanks,
Tom

[1]: https://github.com/php/php-src/pull/1699

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Zeev Suraski]

On Wed, May 1, 2019 at 3:19 AM Peter Kokot  wrote:

> On Wed, 1 May 2019 at 00:56, Stanislav Malyshev 
> wrote:
> >
> > Hi!
> >
> > > Worth noting another inconsistency here that we've missed. PHP 7.4 has
> > > introduced many BC breaks actually already. Without this level of
> > > problems:
> >
> > Exactly, without. There's a difference between removing an unmaintained
> > extension which is barely used and setting people up for displaying
> > their sources if they use slightly outdated libraries. And there's a
> > difference between explicitly making a decision and not even bothering
> > to discuss this mammoth of a BC break until the vote is finished. So to
> > me it's more like "elephant in the room" scenario - we've got a process
> > failure here. We are on the course to correct it, but it's a failure
> > nevertheless.
>
> It is a BC break nevertheless no matter how much time it takes to
> change the code. The level of the impact cannot be measured like this.
>

Of course it can be.  Scratch that - that's not one way to measure it, it's
the only sensible way to measure it.

The only way to look at this is a cost/benefit balance, and here, the cost
is considerably high, and the gain is virtually non-existent.  All the
points the RFC mentions were known and factored in back in 1998, virtually
all of them are either mild or factually wrong - such as the simplication
of the parser (the parser is 100.000% oblivious to whether short tags are
enabled or not, and they're implemented in roughly 10 lines of code that
haven't changed for probably 15-20 years in the scanner).

For mostly everything else deprecated in 7.4 and 7.x in general - the cost
is typically very small - and often the gain is a lot more substantial.  In
other cases, the reason of the deprecation is simply coming to terms with
reality - e.g. that a given extension isn't being actively maintained so we
can no longer support it.

There's no comparison between deprecating a basic building block that's
been with us since 1998 - that will be all over the place in code that uses
it (and there's plenty of that out there), with the deprecation or slight
mods that will be affecting a tiny fragment of the userbase.



> I haven't seen code with short tags for such a long time now that this
> is for me a problem on a scale of a fly.


This is *precisely* *not* the kind of thinking we should have here, and
what I was alluding to when I spoke about responsibility.
The fact you haven't seen code with short tags for a long time, means
exactly that - that *you* haven't seen code with short tags for a long time.
We can also build upon that, as well as feedback from others here and some
indicators and trends in PHP development - and extrapolate that you're not
an outlier here, and in fact, most folks who are at the top 10-20% - at
least - haven't been using short tags for a very long time, if ever.  I
already said that I'm deep in that group as well.
However, that's just one part of the PHP world.  And on internals, we're
supposed to care about the entire PHP world, including parts that are
severly underrepresented here but nonetheless exist and are very large.
There's TONS of PHP development going on behind closed doors, by developers
who probably couldn't care less about PSR's, code beauty and even
portability - given they're writing stuff for internal use.  For others -
they may care more, but have to maintain other people's code that's been
working for ages - and they only have to do the minimal amount of work to
keep it working as new versions are installed.

As a project, we care *greatly *about people upgrading to the latest
version - primarily for security considerations.  The top reasons to
upgrade, in my experience, have been (a) performance, and (b) security -
with features coming at a distant third.  That is especially true for
legacy apps with little active development.  Every BC break we add without
an excellent reason, means that needlessly - fewer people will be
upgrading, and those who would upgrade would do so on a longer time scale.

Because we've simply upgraded
> all very very long time ago or in other words even never thought of
> writing something in these tags anymore. Well, obviously this might be
> for someone else a problem on a scale of an elephant, that I don't
> know and probably won't understand fully. But, also at least now this
> discussion and also RFC brought this thing out - short open tags
> shouldn't be used anymore in any case. :) Because obviously a very
> large number of people would like to have more clear definition of
> what is opening PHP tag.
>
>
To be honest, I don't think it's something at the scale of an elephant for
the vast majority of folks.  But I think that may be cow-sized for many.
The other side of the equation is that the benefit of removing it - is
barely even a fly.  This deprecation brings virtually no value.  The
cost/benefit balance weighs extremely against it.  But you have to be
thinking about th

[PHP-DEV] Re: [VOTE] Arrow functions / short closures

[Nikita Popov]

On Wed, Apr 17, 2019 at 12:58 PM Nikita Popov  wrote:

> Hi internals,
>
> I've opened voting on the arrow functions RFC. The vote closes May 1st.
>
> https://wiki.php.net/rfc/arrow_functions_v2#vote
>
> The RFC uses the fn($x, $y) => $x*$y syntax as originally proposed.
>

I'm pleased to say that the arrow functions RFC has been accepted with 51
votes in favor and 8 against.

Nikita

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Stanislav Malyshev]

Hi!

> Every app will have different things to fix. So saying that this
> particular change will break the internet is not realistic without any
> numbers. If PHP is on a course to fix the BC break strategy then good

I am not saying it will break the internet. Nobody does. What I am
saying it creates a huge and serious risk (both operational and
security) for people upgrading, and I am not sure why it is being
dismissed roughly as "well, BC happens, what you gonna do..." In my
opinion, it's not a kind of issue one should be dismissing. It's not a
regular low-grade BC break, it's a serious and dangerous one. Probably
one of the most dangerous - in its current state, as voted - among all
present in the release.

> even this discussion. Because, from what I think here more is that
> we're discussing how to keep the short tags forever and how to remove
> them as soon as possible. There is a difference in what people want

I don't think dealing in absolutes here is helpful. There are more
options than "ASAP" and "never". And I feel that the RFC as-is have not
considered them thoroughly enough - otherwise I can not see how the
issue of spilling out the source has not been handled.

> removing the tags in the first place. I haven't seen any step forward
> from this point yet and what kind of a different removal strategy
> (compared to Nikita's suggestion) would work.

Whatever removal strategy there is, it should not be "let's switch the
default in 7.4, remove the whole token completely in 8.0 and let people
that have  I haven't seen code with short tags for such a long time now that this
> is for me a problem on a scale of a fly. Because we've simply upgraded

You must realize you haven't seen 99.999% of existing PHP code, and
that's probably if you look at a lot of code? Massive amounts of code
are not public. Massive amounts of code are using old library versions
and old dependencies, a lot of them not easily upgradable to latest
versions because the surrounding code is old too and newest versions
break it.

The fact that you personally haven't seen such code and it's not a
problem for *you* doesn't mean a lot if you purport to take
responsibility over the needs of millions of PHP users. Voting on RFC
should not be an expression of a personal opinion and only it, if it is
we have a grotesque situation where personal whims of barely 50 random
people decide things for millions. This can only work if each of these
people realizes the responsibility inherent in the decisions being taken
and considers the impact that their vote would have not only for their
personal needs, but for other users too.

> know and probably won't understand fully. But, also at least now this
> discussion and also RFC brought this thing out - short open tags
> shouldn't be used anymore in any case. :) Because obviously a very

There's a very big distance from recommending not using short tags to
removing short tags from the parser. We've just voted for covering this
distance in two releases. I think this would be a costly mistake. There
are ways of doing it properly - Nikita's proposal could be one of them.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php