Re: [PHP-DEV] bugs.php.net downtime

[Yasuo Ohgaki]

Hi,

On Wed, Jul 18, 2018 at 5:39 AM Rasmus Lerdorf  wrote:

> Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
> to 7.2 on faster hardware.
>

It feels faster now. Nice work.

Anyway, it seemed UTF-8 char is not handled well.
I tried to send reply with UTF-8 chars

にほんご文字列

for

https://bugs.php.net/bug.php?id=76635

and response is empty page with 500 code.


Request URL: https://bugs.php.net/bug.php?id=76635=1
Request Method: POST
Status Code: 500 Internal Server Error
Remote Address: 206.189.200.141:443
Referrer Policy: no-referrer-when-downgrade


Invalid UTF-8 data stored in bug db can result in broken pages.
How about convert invalid data into URL encoded data or something else?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

[PHP-DEV] PHP 7.0.31 is available

[Anatol Belski]

Hi,

The PHP development team announces the immediate availability of PHP 7.0.31. 
This is a security release. Several security bugs has been fixed in this 
release.

All PHP 7.0 users are encouraged to upgrade to this version.

For source downloads of PHP 7.0.31 please visit our downloads page:
http://www.php.net/downloads.php

Windows binaries can be found on http://windows.php.net/download/

The list of changes is recorded in the ChangeLog:
http://www.php.net/ChangeLog-7.php#7.0.31

Regards,
Anatol Belski and Ferenc Kovacs


P.S. Below is the verification information for the downloads

php-7.0.31.tar.bz2
SHA256 hash: 7e8bd73eced6e679a179d39571e8fee6c83e51c86f43338f65c2dc88c1106b91
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEGk6LcnfELlPbqce5vKow6pwNV2MFAltN0GAACgkQvKow6pwN
V2OrOgf9G8vHzgiBO4mRQczBKqcCl4hpBD1YJ5AHCNOf0+sPHTxRXN5Mqss9T3pe
PIJfBW3xxsEkAI/RzwXhRc9m6sEuqoPYT6Mp3i0oFuUK+YCNUXEgayi7ry408GMB
5if/iq3tH7S0pbgjKV4y48CiXJb8/V8zfV7asgRoSoSCb2CnSjrZGlwGLMSIh3NL
Xt+Sg0G8xLgzxPboTJpCDA2EGUsFBjuv8IGFGD9vAfMKzNR/ZqTRl85Q2NuIMFEV
yHHyxcAkjbC6/69lYntY0ZMgc4BhC6Mr1vXBuvyRn/M5U9eQaNfsjpHPi9rcm6M2
PT3K6Qf4LsDvTXJU81w9DuM4IJXuoA==
=1BRy
-END PGP SIGNATURE-


php-7.0.31.tar.gz
SHA256 hash: 182f36e5709837158bd4970ce57fe80735bdf79025133c00d6ad882d1c4d98dd
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEGk6LcnfELlPbqce5vKow6pwNV2MFAltN0GUACgkQvKow6pwN
V2PjFwgAo2LxWP6T3A77eP6DE6itgUjOOj69WZrbybVu8ENwzhxb1kNvpk5PGee9
vHUdGrivmOGDJO8EeZGvexK1LliwfJ7a1HnEAoL1ob7KKftorrPuO9tCOHIy45/W
QsZnNePwbBBrsJLsfNYno3BotQKGgy+96i9HPaX2RlswFOgbdy86hLNv+XTcCKyL
mrswo1s3lR/hj6bk1AoTtKgW+m76yG4s8PeNtAGF1Z92Sysnaa4aGCHtStxOTaMp
VuMPm47NbdDOCk7cFm2z/CkzB8Pq0ShxtbiDwy39BC9MRmmjDM/YqOxzX8mVEpXZ
ok5PCT1i616JRDxwRg1Z1lKnpluXeg==
=sfGN
-END PGP SIGNATURE-


php-7.0.31.tar.xz
SHA256 hash: 68f57b3f4587071fb54a620cb83a1cfb3f0bd4ee071e0ce3bf7046a5f2d2f3cf
PGP signature:
-BEGIN PGP SIGNATURE-

iQEzBAABCgAdFiEEGk6LcnfELlPbqce5vKow6pwNV2MFAltN0GUACgkQvKow6pwN
V2PuqQf/fBX+ZKmKQeFz/EgsfzbSTqWOjJg00SzCBWdzy9HzfGi1hktV7O7iT9Ku
827SCyQ/yJSHQUS9SwpeDMnmGLsFs9JSSH0uBLTDrLRgoNJCZoA/j2R0JNoKaHFm
0+U1w45vjHlDkFV6BRua8oNdt72uUEQVXgu0wyMBAg3GVroyzden2uN5Qh6e/xsG
YWqDxbjYbY+zBs1DIrr2h1y7EaHggKS07WCEtKBjH5hRb7VzMUdqIzKowOyuwzSd
puSTRxbcizTYnwasWpC00P4AnUyjARFgn3t0GOHw4iz14I0qadD2PFzVD0rnw36U
Zw5/PpL8cQja5d3FmpenYx7J7+utSQ==
=f6w7
-END PGP SIGNATURE-


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

Re: [PHP-DEV] Non-nullable properties

[Larry Garfield]

On Thursday, July 19, 2018 10:01:58 AM CDT Rowan Collins wrote:
> On 19 July 2018 at 15:20, Christoph M. Becker  wrote:
> > It seems to me that either of these proposals would render the lazy
> > initialization pattern outlined in the “Overloaded Properties”
> > section[1] invalid.
> > 
> > [1] 
> 
> Hm, I guess I didn't read that section carefully enough.
> 
> It strikes me that that entire code pattern is a hack due to lack of
> property accessors, and it seems a shame to reduce the usefulness of the
> language's type system just to support it.
> 
> From the responses on this thread, I get the feeling I'm in the minority,
> but it still feels utterly wrong to me that a property marked as
> non-nullable offers no guarantee at all that it will actually hold a valid
> value.
> 
> Regards,

I get the sense that it should be treated as a bug in the implementing code, 
not calling code.  That is, given:

class Foo {
  public Bar $bar;
}

If you call (new Foo)->bar and get a type error, you should not add null 
checks but walk over to the Foo author's desk and slap them upside the head.  
(Aka, file a bug report.)

I can see the value of punting there, and it's hardly the first time PHP has 
punted on something in that fashion, but I agree that the whole point of such 
checks is to make sure that the Foo author *can't make that mistake in the 
first place*.  That's rather the point of all type hints in PHP.  The more 
errors are compile time errors the better.

I wouldn't mind dropping that overloading behavior if it gave us more 
guarantees about property validity.

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] bugs.php.net downtime

[Hoffman, Zachary Robert]

On Thu, 2018-07-19 at 22:35 +0200, Niklas Keller wrote:
> Hey Rasmus
> 
> I just found this bug: https://bugs.php.net/bug.php?id=76553
> 
> Has this bug been like that before the migration, too? Or did
> something go wrong?

No, those used to be Unicode characters from the cyrillic block.


https://web.archive.org/web/20180719203931/https://webcache.googleusercontent.com/search%3Fq=cache:https://bugs.php.net/bug.php%3Fid=76553

(https://tinyurl.com/it-used-to-look-like-this)

--
Zach Hoffman


smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Improvements to openssl_crs_new. Need advice

[Niklas Keller]

Hey,

I'd prefer a proper OO API in case we add new features in that area.

Regards, Niklas
Am Do., 19. Juli 2018 um 01:05 Uhr schrieb Jakub Zelenka :
>
> Hi,
>
> On Wed, 18 Jul 2018, 00:15 Dominic Luechinger, 
> wrote:
>
> > I'd like to improve the openssl_csr_new function to add any X509
> > "Requested Extensions" [1] to a CSR.
> > My motivation to improve this functionality is to avoid workarounds like
> > altering a openssl.cnf file and pass some ENV variable to it [2].
> >
> > I already implemented the following new functionality:
> >
> > Old:
> > mixed openssl_csr_new ( array $dn , resource &$privkey [, array
> > $configargs [, array $extraattribs ]] )
> >
> > New (I can provide a patch, needs cleanup and testing):
> > mixed openssl_csr_new ( array $dn , resource &$privkey [, array
> > $configargs [, array $extraattribs[, array $extraexts ]]] )
> >
> > E.g:
> > ```
> > $privkey = openssl_pkey_new();
> > $csr = openssl_csr_new([], $privkey, null, [], [
> > 'subjectAltName' => 'DNS:example.tld',
> > ]);
> >
> > ```
> >
> > While implementing the new functionality I realized that the 'Requested
> > Extensions' are represented as a CSR attribute and it contains the ASN1
> > structure of multiple extensions and their definitions. With the
> > following example the declaration of the extension should be possible
> > without the new argument $extraexts in openssl_csr_new.
> >
> > ```
> > $privkey = openssl_pkey_new();
> > // Use OID of ExtensionRequest
> > $csr = openssl_csr_new([], $privkey, null, ['1.2.840.113549.1.9.14' =>
> > 0xDEADBEEF]);
> > ```
> >
> > This won't work because the argument $extraattribs only applies to
> > subject attributes. The argument name is kind of misleading. See the
> > following bug report [3] from 2008 that describes the issue in a good
> > manor. IMHO this bug report is valid and the bug should be fixed in a
> > way that the attributes are added to the certificationRequestInfo [4]
> > instead being merged into the subject. This might break some existing
> > usage of this argument. With this bug fixed 'Requested Extensions' can
> > be added in a programmatic way. To generate the DER encoded content of
> > 'Requested Extensions' a ASN1 library should be used.
> >
> >
> > Now comes to tricky part about supporting my initial goal to add
> > additional'Requested Extensions' to an CSR.
> >
> > Should I summit my patch with the extra argument as a PR or should I fix
> > the bug 45076 or should I do both?
> >
> > extraexts VS bug fix:
> > - No BC break VS BC break
> > - No need for a ASN1 library VS working with ASN1 DER encoded data
> > - Default extensions from openssl.cnf are preserved and can be
> > overwritten VS definition of 'Requested Extensions' in DER overwrites
> > default extensions from openssl.cnf
> >
> > Looking at the pros and cons my guts tells my to do both. Patch and bug
> > fix.
> > Any other suggestions/thoughts?
> >
>
> I haven't had time to properly look into it but from the quick read, I
> would prefer not to break BC even though the behaviour seems incorrect. I
> think that changing that can cause some issues potentially. But I might
> need more time to think about. Anyway the proposed patch seems reasonable
> so it would be great if you can create a PR that.
>
> Cheers
>
> Jakub
>
> >

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

Re: [PHP-DEV] bugs.php.net downtime

[Niklas Keller]

Hey Rasmus

I just found this bug: https://bugs.php.net/bug.php?id=76553

Has this bug been like that before the migration, too? Or did
something go wrong?

Regards, Niklas
Am Do., 19. Juli 2018 um 10:35 Uhr schrieb marius adrian popa
:
>
> Hello Rasmus,
>
> I can't access previous patches
>
> https://bugs.php.net/patch-display.php?bug_id=62300=0=latest
>
> On Tue, Jul 17, 2018 at 11:38 PM, Rasmus Lerdorf  wrote:
>
> > I need to move bugs.php.net to another server sometime today. I won't be
> > able to do it without a little bit of downtime as I have to stop new
> > activity on the existing box, copy the DB over and then point DNS to the
> > new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
> > much longer than that.
> >
> > Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
> > to 7.2 on faster hardware.
> >
> > -Rasmus
> >

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

Re: [PHP-DEV] Non-nullable properties

[Rowan Collins]

On 19 July 2018 at 15:20, Christoph M. Becker  wrote:

> It seems to me that either of these proposals would render the lazy
> initialization pattern outlined in the “Overloaded Properties”
> section[1] invalid.
>
> [1] 
>


Hm, I guess I didn't read that section carefully enough.

It strikes me that that entire code pattern is a hack due to lack of
property accessors, and it seems a shame to reduce the usefulness of the
language's type system just to support it.

>From the responses on this thread, I get the feeling I'm in the minority,
but it still feels utterly wrong to me that a property marked as
non-nullable offers no guarantee at all that it will actually hold a valid
value.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Non-nullable properties

[Christoph M. Becker]

On 19.07.2018 at 15:41, Rowan Collins wrote:

> On 16 July 2018 at 17:09, Larry Garfield  wrote:
> 
>> class Foo {
>>
>>   protected Bar $b;
>>
>>   // This runs before __construct, is not inherited, and cannot
>>   // ever be skipped.  If this method exits and any property is still
>>   // value-less, TypeError immediately.
>>   protected function __init() {
>> $this->b = new Bar();
>>   }
>>
>>   public function __construct() {
>> Behaves as it always has.
>>   }
>> }
>>
>> That's similar to the "initialize" flag inside the constructor, but splits
>> it
>> off to a separate method that is devoted to just that purpose; it
>> therefore
>> has no parameters, ever, and if you want to initialize an object property
>> based on a constructor argument then you must either make it explicitly
>> nullable or initialize it to a dummy value first.
> 
> The extra method certainly feels more "PHP-like" than an extra keyword, but
> as you say, calling it automatically makes it awkward to initialise based
> on any kind of input.
> 
> A couple of variations on the theme:
> 
> a) __init() takes the same arguments as __construct(), but is called first.
> This might be rather confusing, though - we could insist on the signatures
> matching, but people might be surprised that their constructor parameters
> are passed to their object twice in different methods.
> 
> b) __init() is not called automatically, but has to be called manually,
> with whatever parameters you want, as the first line of __construct(). This
> feels a bit weird, because no other method name causes special behaviour
> when called manually. On the other hand, it allows it to be called in other
> situations, such as unserialize, which by-pass the constructor.
> 
> A compromise system which doesn't need new keywords or magic would be to
> combine the current error-on-access behaviour with a check at the end of
> the constructor.
> 
> So:
> 
> = as soon as the constructor starts, $this is available as normal
> = accessing non-nullable properties of $this before initialising them would
> give an error (as in the current proposal)
> + when the constructor returns, the engine checks that all non-nullable
> properties have been correctly initialised, and immediately throws an error
> if they have not
> + Serializable#unserialize() could run the same check, since it is
> effectively a constructor
> = ReflectionClass#newInstanceWithoutConstructor could just allow the
> incomplete object, since such an object is not likely to work smoothly
> anyway
> 
> Since $this can be passed to other functions and methods by the
> constructor, there is still a chance of code outside the class seeing an
> incomplete object and getting errors, but the distance between cause and
> effect (which is my main objection to the current proposal) is massively
> reduced.

It seems to me that either of these proposals would render the lazy
initialization pattern outlined in the “Overloaded Properties”
section[1] invalid.

[1] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Non-nullable properties

[Rowan Collins]

On 16 July 2018 at 17:09, Larry Garfield  wrote:

> class Foo {
>
>   protected Bar $b;
>
>   // This runs before __construct, is not inherited, and cannot
>   // ever be skipped.  If this method exits and any property is still
>   // value-less, TypeError immediately.
>   protected function __init() {
> $this->b = new Bar();
>   }
>
>   public function __construct() {
> Behaves as it always has.
>   }
> }
>
> That's similar to the "initialize" flag inside the constructor, but splits
> it
> off to a separate method that is devoted to just that purpose; it
> therefore
> has no parameters, ever, and if you want to initialize an object property
> based on a constructor argument then you must either make it explicitly
> nullable or initialize it to a dummy value first.



The extra method certainly feels more "PHP-like" than an extra keyword, but
as you say, calling it automatically makes it awkward to initialise based
on any kind of input.

A couple of variations on the theme:

a) __init() takes the same arguments as __construct(), but is called first.
This might be rather confusing, though - we could insist on the signatures
matching, but people might be surprised that their constructor parameters
are passed to their object twice in different methods.

b) __init() is not called automatically, but has to be called manually,
with whatever parameters you want, as the first line of __construct(). This
feels a bit weird, because no other method name causes special behaviour
when called manually. On the other hand, it allows it to be called in other
situations, such as unserialize, which by-pass the constructor.



A compromise system which doesn't need new keywords or magic would be to
combine the current error-on-access behaviour with a check at the end of
the constructor.

So:

= as soon as the constructor starts, $this is available as normal
= accessing non-nullable properties of $this before initialising them would
give an error (as in the current proposal)
+ when the constructor returns, the engine checks that all non-nullable
properties have been correctly initialised, and immediately throws an error
if they have not
+ Serializable#unserialize() could run the same check, since it is
effectively a constructor
= ReflectionClass#newInstanceWithoutConstructor could just allow the
incomplete object, since such an object is not likely to work smoothly
anyway

Since $this can be passed to other functions and methods by the
constructor, there is still a chance of code outside the class seeing an
incomplete object and getting errors, but the distance between cause and
effect (which is my main objection to the current proposal) is massively
reduced.



Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Re: [RFC] Typed Properties

[Dmitry Stogov]

I've run few benchmarks, to measure the performance penalty of this proposal.


https://gist.github.com/dstogov/b9fc0fdccfb8bf7bae121ce3d3ff1db1


In most cases real-life apps become ~1% slower. In the worst case, I got 6% 
slowdown (on mediawiki).


Thanks. Dmitry.


From: Zeev Suraski 
Sent: Thursday, July 19, 2018 11:52:37 AM
To: Nikita Popov
Cc: Zeev Suraski; Internals
Subject: Re: [PHP-DEV] Re: [RFC] Typed Properties

On Tue, Jul 17, 2018 at 9:02 PM Nikita Popov  wrote:

>
> Sure, we can wait another week. Unless the additional discussion results in
> major changes to the RFC, we'll start voting next Monday (2018-07-23). In
> the interest of avoiding further delays, please try to view this as a hard
> deadline: If you would like to discuss some aspect of the proposal or raise
> a concern, please do so now rather than on Monday morning.
>

I reviewed the proposal in detail - and quite detailed it is.  It seems
like you and Bob did a very thorough job here, kudos on that.

I do have 3 comments - none of them major - but I think should be addressed
nonetheless:

1. The RFC is surprisingly sparse on examples where the typed properties
are not scalar ones.  So much, in fact, that I had to check whether this is
intentional (i.e., classes are unsupported as enforced property types) or
an oversight.  Reviewing the 'Supported Types' section, while mentioning a
ClassOrInterface - isn't entirely clear, as it's unclear whether this is a
token, or something that stands for any class name or interface.
Thankfully the proposal does cover class and interface names as property
type definitions.  I would recommend to be explicit here, and say "any
class or interface name", and ideally also provide a sample of that option
in the Introduction section of the RFC.
2.  While trying to understand whether #1 was in fact supported and
reviewing the patch, I noticed that there were several comments from Dmitry
on the patch (within the pull request).  It would be nice if they were
addressed (none of them will turn the patch upside down, and as I see it
they are orthogonal to the vote).
3. The patch does bring a performance penalty, albeit quite small (every
property assignment now has to conduct type safety checks).  This does not
only affect code that uses typed properties - but also code that doesn't.
I think this should be mentioned in the RFC.  To be clear - I don't think
the penalty is substantial enough to change someone's opinion about the
merits of the proposal one way or another - but in the spirit of full
disclosure it should be there.

Zeev

[PHP-DEV] PHP 7.2.8 Released

[Remi Collet]

Hi,

The PHP development team announces the immediate availability of PHP
7.2.8. This is a security release which also contains several minor bug
fixes.

All PHP 7.2 users are encouraged to upgrade to this version.

For source downloads of PHP 7.2.8 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.


Release Announcement: http://php.net/releases/7_2_8.php
Downloads:http://www.php.net/downloads
Windows downloads:http://windows.php.net/download
Changelog:http://www.php.net/ChangeLog-7.php#7.2.8


Many thanks to all the contributors and supporters!


Sara Golemon, Remi Collet




php-7.2.8.tar.gz
SHA256 hash:
a0cb9bf2f78498fc090eb553df03cdacc198785dec0818efa7a1804c2b7a8722
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJbTYcUAAoJENyf+NPuWvJ/mnkQAJyGPUoytbfHWt6ABS0MefF8
lJdcM29EkvDeFYTXj4sAU5Ikyu/+Jd+4mcnvSkUQA+XLOvfwUyt6/9IyyM+yj+e2
E9oZmBy28FnVTodvKUXz8y7OPYWA8jrG0db+SJv8EVD1pn0VywqxKOKZL4wuUGJm
ySRQuu9hfKFTVSBdgPAkmpNAztDer6cA9dhE6MuEkH3k8MhCDUUPMzVO4HUfwQnX
PP04E3wvGWHDWt45T9zdaqxpL4mVvuMhKDPctJrn9uaOBqYz8Zwp/WKgi23P5sbQ
ps+YmH0WTIx02E8MpTgt9HQYx2aicfjrNxMR50yxleA6ihyO+32kmttDlakaJl1f
hqa/RB+nYenF+RvgQasakLCwQxNSl/QUVcH43p+yX22iyKvvc6g25umsmnEYfEqF
u42hlfNpaN1MMYmTjA66iC7/eIobsqxMt0U1FPQuK+22qIbAt4Dk7izh4MB3u2VY
k2TZn32BcBFzAjLk7/b3xG/OsQ9/q6wNz3id44IKpUUOTq6stbQRQiXco8kNpZ5Z
5krOcmbyImiZvOH8YCRj1KX+x5M3uT3B5kmhKZY3t+4Ys64+imopabI+YqDnR8ZC
2wNvjAW1dGS2sc4MxSYUEFW1Nv75GhljfOn+lvr0TjcV3hrzRNENUd6cxXkrVwTS
5eqvgT6by81KV8F6Nvsu
=WxLL
-END PGP SIGNATURE-

php-7.2.8.tar.bz2
SHA256 hash:
1f8068f520a60fff3db19be1b849f0c02a33a0fd8b34b7ae05556ef682187ee6
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJbTYcYAAoJENyf+NPuWvJ/tMIP/33P7530lbNNibXKee2uneDr
O5ZHvQRJlBZpF0yG5zEz8UR1hArw6Yo+no8sksuOVP48gHFFwdk30dT8fzBlNsMh
2an742UEVGijWSHRQlSObMp2PzqcsI1/1fLoBC+fMOp9/c0B+cse5agj0v1cNNJ5
6uV+G6tESyx7t3OXXj48LRDbigta+SvrZibuloL3qFXYL4cpiDJsm9PZWF7l8aVh
E0ncu4oaYrGPxw9jYNJgebq83BHeGGhYq0wJ9kH7LNbUWfP8HTII3c/Rmwr017I5
rA8LzXRZDn8LpZPayJrzbAOeCb9RkGl+ACDHUFxA1IDHrhHvQb57ppnagsmUAfAb
GVtN7LD4ZnEzuCHlBbXZDaWNuxVOVlxXEbl01kpYgvXrKVdsHfpdWDk4N5X7T7+D
bGDm+upxMZw07MJUjCLxhQBPovgqHTczl/iKuN358/YFbZTDOA8plydv5gQoVQ0a
kva75VcJGyrxM1uQAKKFvVnTuQvaMY0Z3ra7cLE9oN26Z6lAsfeGBKOQAqytebE+
+9jREhRCvpew8EcKahgUl/w9DAqWHzFMJWnLTlbL68/arkUnYZVAUwHUXwsKl+oy
6Mx4pCGqs4XM/2y72/AdDcX9KXAAyCzpmt7FLj9TUMnZaQdoav4Iev0Qv64XO2aa
F2VMusDce2SGtQ4HYULr
=vXS7
-END PGP SIGNATURE-

php-7.2.8.tar.xz
SHA256 hash:
53ba0708be8a7db44256e3ae9fcecc91b811e5b5119e6080c951ffe7910ffb0f
PGP signature:
-BEGIN PGP SIGNATURE-

iQIcBAABAgAGBQJbTYcaAAoJENyf+NPuWvJ/Q2wP/Raylawjhnw+E8iuwCyPbNni
PmudNHfrWz9JKpMPnt/Q3ULDT2UR40Lpr78lL0KKC6je0CRCp/ajiB64L6DVzOQu
dhetrSr0BqM3mwCEme2qfCx+Qme8czXUdVaze6s5LoOrdLkdJrUB+CLWbCzIijl4
6bdLVcwQ49Dc0kGR8VUnEKwYQWmjb4NIMe+O+DQxynThvNqEhgLTfVuLKgfl/q/V
581+oDtWZfPJmwQa8t8eT9J4/bq638hKpUzFXAAFF5edT3HAdySkPAEA8lqTrcik
R3jB5fwMo2aqP4KPERyuY4g6Lpso4sx088AY1PiEO7BEYfJ8Zec3rpht4xMbfLfq
GQ47BoMRH3eOxrKWPDdQ47GnDWxTeJroJ5WEbkVu8q7EdNwOaW8AyfyT5drMAkI7
3wiG2ptdFoaPFF0J3S//fXCvS5zooDhyQhqYD0WaYYPXbAuY6rePsdo/JtTZv2KV
1DW8PWW6W0eyKZItsPzwoclJ0maPEYjSvEVs+mSjpmPTxF7d9e+Im1kBNOA1xzXS
H4TxHHgzB00Ljxc8DTngQypLYWG9Gf+wO5UAare7ChhB6dSef+2aA9dRxRQVn2js
CvGnRkF7bvIqkUWIWomzCbMFweQafYq0kzqZMkClcpKK0ptvIEFj5r3C8xNC90cJ
37wKYiV63RHaPnnxd72/
=qac7
-END PGP SIGNATURE-

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

[PHP-DEV] PHP 7.3.0alpha4 is available for testing

[Christoph M. Becker]

Hi all!

The PHP team is glad to announce the release of the fourth PHP 7.3.0
version, PHP 7.3.0alpha4.  The rough outline of the PHP 7.3 release
cycle is specified in the PHP Wiki: .

For source downloads of PHP 7.3.0alpha4 please visit
.  Windows sources and binaries can be
found on .

Please carefully test this version and report any issues found in the
bug reporting system at .

THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!

For more information on the new features and other changes, you can read
the NEWS file
(), or the
UPGRADING file
() for a
complete list of upgrading notes.  These files can also be found in the
release archive.

The next release would be Beta 1, planned for August 2nd.

The signatures for the release can be found at
 or below:

php-7.3.0alpha4.tar.bz2
SHA256 hash:
bb89c2c21243bd7cf2bdd69d1a1ff8782775f33e84cc8451369317b03e45e936
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAltN+HkMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2fD8P/1z+LvbuOMj/WqUo/5GXJuHAzEIk4hFUmK3m11GN
h72sXfRzdj28HnVJ5kOl0D5Ern4Zi5Ygs0A18sB5nwZBMo4af9xVLWrIyElpW6qY
P6wkfK6uaqt7S6dQyFI4RX/3Ux6lHxvenEFFhfWCuqcv1nFr36AWGIToSo9qCOrV
BfWxOOkRLVqCndZBZJ0f5BsbTlhvvFFZEtUbfGwC+1797H1bprgPvtTaZiVi2pw2
DPhz6BoX4BOB2czZjbmD8LopMLQeySp8j9mu6A4n9R2KCi1vZo7/fJHy63x82pJx
CWvy4qSqROIqOLh/bdHi8TuwDsaeL3U9yAYVhHmFHXBWgi0PiY6y7dVRz/SE6FAt
CNCAewX3NCSLjuj59vv26oy8VMxlJYQFWMZRh/np5v+oIqv+2A+IV80yM2ISkzHi
n3dZA3M0/7aQQcIrImfUyzrinsEb5HiIddPglbcA0tWaRS3SYDrtkuSodZITiVr6
vNtcnnJPtt8YjblNrWfVYmz6B1C7OMvhWZR9olhmwgWzZtD+52FgN1MZNfT1U8nn
CxMj0CBJYM53SXLJi6zjCAvhGLqJr6NIyjswJwKp67SCaGSODNSpkXEXdRf52jYf
3BdD2qMFkmL+txWUBzCn/LqqwjNts6LQKOdrMTT+7Nvd5kdfM1a5575LU3jXgpcv
bWju
=x7DA
-END PGP SIGNATURE-


php-7.3.0alpha4.tar.gz
SHA256 hash:
eb668e9b57348e4aed509683b885d0cf60b671096e313c872907f91d7f42bc17
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAltN+IIMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y2j6YP/2c8ywsmKQGTIr6HSrtlAR4Ef04xI98v1CbIrCrh
j1W+zNl+ZJkZMpzyhym68Ug2m2PWYeAMdURgfksiB/kQh07jwIxCo7Id5V+lgkDJ
epQDU/2et+9R+qZfu8PQKGTCeN2feHDXBlbVmKZiARI1YlA7+JqdWfQ53s7uo0J6
Hffm2Un08RO2v6e/tJbyspFuDwFRe3fUDQKX6c0P3EFjRHQKB/2WtNLHLbt549Sx
0JlueOMHWD92Jjl1MgqL969/fQaeZnzh4ChtLzZXeb+xFJd1Quao18iUapTEAx3v
mg/okfsidupV4d13rn9IbT3506e9l6c3VDjQHWLI/ru+kO3E5ydpT/VeDHH+sb3O
PDxUyad2zrfkMvQGel9DRWISM1XNh6XyA+S29DQqP+WcuSwFUR9MYdBsQj5If1DG
0eOXCMZY56hc/jSX+dcZznQJl36JoFsVHxKIlPVNyoSBgoGUFtBpDnTzdCdBYUY+
E4wTQBTSsLAthrh5y18iXRxxr1yEa77OQ+kve0OInepWHQUJY+P8auQX5lDfG6mv
ghl3J8EaZXUl8dzjZ+cDNyviIgNtoEOgpvq1vGpc2a1QajIy5gJ7XIUfGwwXds1k
wE2FxRHXbNCF0wOiOQXB+qyjaskkm/oAIfn5SOe7uNoARIPg0lfqVszMwG9cvWHA
L+Ja
=hx9u
-END PGP SIGNATURE-


php-7.3.0alpha4.tar.xz
SHA256 hash:
32670f40aecce130727d841e3191d30237caff643a239d3c16cd579e762bc4c6
PGP signature:
-BEGIN PGP SIGNATURE-

iQJABAABCAAqFiEEy69p8XOg/qS1N/Rw1myVkxGLzLYFAltN+IIMHGNtYkBwaHAu
bmV0AAoJENZslZMRi8y22w0P/R+ouM9KVh9ssAuITgk9bc3JCanESemE5h2qKiWA
/h4MS3aho/LpResN1E4H4Hg7WMjK31yy5p1k7O4r5cOhReWSMYaXgp90zb9aidFy
CbW08Ky07TOBxJ/Wr4Ai+nzYZDjz6qnNEWTgp0MTIg7d5ZQ5sNv05dv9fYgRzHUd
gYgYhWNQP4G/hhWxK9j02TZoRGhuUXGKaR/w11uyW1qeccVknr57MnCr0Pquf/Mb
z4Dm8zELgw26vOdHURHnH5mrscVzVIBRzZKTReGH/BXXNKT8c52lY05ZxdM6P5Dj
RO/9X/h7HTnOFdQL9pgo3G385qBTX9I7Jzvy/4iEqxBvxzx3hhAiGv/gG93pco1B
NX3GMVmxrOLVe/Vn7bbTrXldbU4IHPmhNfBUuRydSP+1cef116kJAG8lquLj9q6i
VS4IRJoZ8OIz0b+HQZzlHRHHOn0zHTwLBkKKPXCLA6y1IwlE33HPwjNAd7J3FLMz
A5sJltF/1Fqt+h3UzM8MgHBRDAs9NOhClCRHAgBcRWNCVJEIRRW7XooJOxAImGvN
swTp0fVKP/XNtTohyQYGIHYapCI1y519ZN5eEfn8lWkRdInQibTofi9oYg6l3D4M
/f6sgN1bXw8GclOKfVn+hB2wsgPnUWbtFjkNpnd9zy7jZw/5e5XhvOIXpuctfwjZ
ube1
=ywtn
-END PGP SIGNATURE-

Thanks,
Your friendly neighborhood PHP 7.3 RMs


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

Re: [PHP-DEV] Re: [RFC] Typed Properties

[Zeev Suraski]

On Tue, Jul 17, 2018 at 9:02 PM Nikita Popov  wrote:

>
> Sure, we can wait another week. Unless the additional discussion results in
> major changes to the RFC, we'll start voting next Monday (2018-07-23). In
> the interest of avoiding further delays, please try to view this as a hard
> deadline: If you would like to discuss some aspect of the proposal or raise
> a concern, please do so now rather than on Monday morning.
>

I reviewed the proposal in detail - and quite detailed it is.  It seems
like you and Bob did a very thorough job here, kudos on that.

I do have 3 comments - none of them major - but I think should be addressed
nonetheless:

1. The RFC is surprisingly sparse on examples where the typed properties
are not scalar ones.  So much, in fact, that I had to check whether this is
intentional (i.e., classes are unsupported as enforced property types) or
an oversight.  Reviewing the 'Supported Types' section, while mentioning a
ClassOrInterface - isn't entirely clear, as it's unclear whether this is a
token, or something that stands for any class name or interface.
Thankfully the proposal does cover class and interface names as property
type definitions.  I would recommend to be explicit here, and say "any
class or interface name", and ideally also provide a sample of that option
in the Introduction section of the RFC.
2.  While trying to understand whether #1 was in fact supported and
reviewing the patch, I noticed that there were several comments from Dmitry
on the patch (within the pull request).  It would be nice if they were
addressed (none of them will turn the patch upside down, and as I see it
they are orthogonal to the vote).
3. The patch does bring a performance penalty, albeit quite small (every
property assignment now has to conduct type safety checks).  This does not
only affect code that uses typed properties - but also code that doesn't.
I think this should be mentioned in the RFC.  To be clear - I don't think
the penalty is substantial enough to change someone's opinion about the
merits of the proposal one way or another - but in the spirit of full
disclosure it should be there.

Zeev

Re: [PHP-DEV] bugs.php.net downtime

[marius adrian popa]

Hello Rasmus,

I can't access previous patches

https://bugs.php.net/patch-display.php?bug_id=62300=0=latest

On Tue, Jul 17, 2018 at 11:38 PM, Rasmus Lerdorf  wrote:

> I need to move bugs.php.net to another server sometime today. I won't be
> able to do it without a little bit of downtime as I have to stop new
> activity on the existing box, copy the DB over and then point DNS to the
> new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
> much longer than that.
>
> Hopefully the new box will be a bit quicker too. It is moving from PHP 5.5
> to 7.2 on faster hardware.
>
> -Rasmus
>