> The type widening RFC makes it easier to move to parameter types for
existing libraries.
I'm curious to see how you'll set the version constraint in your
composer.json file.
After adding a scalar type-hint to an interface, which is a breaking change
in 7.0 and 7.1, but a non-breaking change in
Hi Jakub,
do you know how I can check whether a certificate is in the trust store or
not?
Regards, Niklas
2017-05-29 22:00 GMT+02:00 Jakub Zelenka :
> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller wrote:
>
>> Morning Internals,
>>
>> I have updated the RFC to use a "min_signature_bits" setti
https://wiki.php.net/rfc/release-md5-deprecation
Primary discussion points: Deprecate or Remove? Deprecate for how long?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> As a C++ developer, I have no inherent problems with this **in
> theory**, but I agree with your statement that it's a bit symbolic
> soupish. I also suspect that we'll run into grammar ambiguities.
> Imagine: [ []($x) => $x ]. This is current legal syntax (at the
> point of compilation) beca
On Mon, May 29, 2017 at 10:48 PM, Levi Morrison wrote:
> Based on the discussion there are a few different syntax choices that
> we probably just need to vote between. It's a feature that people seem
> to want but everyone seems to prefer a different syntax choice.
>
> 1. fn(params) => expr
>
On Mon, May 29, 2017 at 4:47 AM, Björn Larsson
wrote:
> Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
>
>>> Any plans to go with this for 7.2?
>>
>> I have been working on this RFC a bit in the last two weeks and intend
>> to start voting within the next week.
>
> Any hope this one will make it i
On Mon, May 29, 2017 at 8:20 PM, Stanislav Malyshev wrote:
>> Is that worth a shot, do you think?
>
> Definitely. There's no reason also why it shouldn't work so failing
> tests in such scenario probably should be treated as bugs.
>
> A lot of tests also inherently parallel-safe - probably majorit
Results for project PHP master, build date 2017-05-28 19:24:04-07:00
commit: 85b0b8a
previous commit:e5c273d
revision date: 2017-05-28 21:15:52+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi!
> Is that worth a shot, do you think?
Definitely. There's no reason also why it shouldn't work so failing
tests in such scenario probably should be treated as bugs.
A lot of tests also inherently parallel-safe - probably majority of
them, though wouldn't claim I am 100% sure - so maybe marki
Hi,
It seems that five years ago I was chatting on the php.internals irc and
I was asking wether documenting the source code with doxygen was
something that it could be worked on, but it seems that most core
developers where against having lots of code comments on the engine
code. So I sugges
Hi!
> People are complaining over at Reddit [1]
Isn't it what Reddit is for? ;)
> I know that this is probably a topic nobody cares much about, at least
> we did not end up in this kind of bikeshedding in the UUID discussion
> thread, but it is after all an important question when designing a la
Hi!
> I used Doxygen in both PRs to document the code. Right now the code base
> is lacking a lot of documentation, which, if done right, would greatly
> improve accessibility of the code base.
Well, the problem as I understand it is that we don't have Doxygen setup
for docs generation. So, addin
On 5/24/2017 12:33 PM, Fleshgrinder wrote:
> Hey internals!
>
> Nikic recommended that we discuss this topic before my latest PRs can be
> merged.
>
> https://github.com/php/php-src/pull/2523
> https://github.com/php/php-src/pull/2535
>
> I used Doxygen in both PRs to document the code. Right no
Hey guys!
People are complaining over at Reddit [1] about using PHP, Std, UUID,
... in other words about case.
I know that this is probably a topic nobody cares much about, at least
we did not end up in this kind of bikeshedding in the UUID discussion
thread, but it is after all an important ques
In my opinion, we can implement it for primitives and arrays, but it's a
bit more political problem than a technical one.
On 29 May 2017 at 19:24, Sara Golemon wrote:
> On Mon, May 29, 2017 at 6:41 AM, Björn Larsson
> wrote:
> > I wonder if the accompanying RFC will move forward?
> > - https://
Hi Niklas,
> -Original Message-
> From: Niklas Keller [mailto:m...@kelunik.com]
> Sent: Monday, May 29, 2017 10:14 PM
> To: Anatol Belski
> Cc: Nikita Popov ; PHP Internals
>
> Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants
>
> Hey Anatol,
>
>
> Niklas, I'd have
2017-05-29 16:03 GMT+02:00 Lauri Kenttä :
> On 2017-05-29 13:58, Niklas Keller wrote:
>
>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>
>
> At least that name is misleading. Most PHP users would probably wonder why
> a setting of 128 does not allow the 160-bit hash from
2017-05-29 22:00 GMT+02:00 Jakub Zelenka :
> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller wrote:
>
>> Morning Internals,
>>
>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>
>>
> Wouldn't be better use security levels instead as it is in OpenSSL? Of
> course I mean ju
Hey Anatol,
> Niklas, I'd have yet a question about the RFC - it only deals with stream
> wrappers, but there are indeed some other places at least in soap and
> mysqlnd. Don't you think, the RFC and implementation should recapitulate
> those?
>
Do you have a link to those places?
Regards, Nikl
On Mon, May 29, 2017 at 11:58 AM, Niklas Keller wrote:
> Morning Internals,
>
> I have updated the RFC to use a "min_signature_bits" setting instead.
>
>
Wouldn't be better use security levels instead as it is in OpenSSL? Of
course I mean just for sig level to not re-implement everything. Basical
On Mon, May 29, 2017 at 9:18 AM, li...@rhsoft.net wrote:
>
>
> Am 29.05.2017 um 09:48 schrieb Niklas Keller:
>
>> Morning,
>>
>> I hereby open the vote on the "Improved SSL / TLS constants" RFC.
>>
>> This RFC proposes to change PHP's TLS constants to sane values. This
>> change
>> has been avoid
On Mon, May 29, 2017 at 7:59 PM, Anatol Belski wrote:
> Hi,
>
> > I'd really prefer if this RFC targeted current patch branches. I
> see
> > minimal BC impact from the change (issues may only arise when
> communicating
> > with broken TLS implementations), while *not* making the change is
>
Hi,
> I'd really prefer if this RFC targeted current patch branches. I see
> minimal BC impact from the change (issues may only arise when communicating
> with broken TLS implementations), while *not* making the change is effectively
> a BC break as more servers stop supporting TLS 1.0.
>
>
On 2017-05-29 13:58, Niklas Keller wrote:
I have updated the RFC to use a "min_signature_bits" setting instead.
At least that name is misleading. Most PHP users would probably wonder
why a setting of 128 does not allow the 160-bit hash from SHA-1 or the
512-bit RSA. So the name should be more
2017-05-29 12:56 GMT+02:00 Nikita Popov :
> On Mon, May 29, 2017 at 9:48 AM, Niklas Keller wrote:
>
>> Morning,
>>
>> I hereby open the vote on the "Improved SSL / TLS constants" RFC.
>>
>> This RFC proposes to change PHP's TLS constants to sane values. This
>> change
>> has been avoided by the p
2017-05-29 10:18 GMT+02:00 li...@rhsoft.net :
>
>
> Am 29.05.2017 um 09:48 schrieb Niklas Keller:
>
>> Morning,
>>
>> I hereby open the vote on the "Improved SSL / TLS constants" RFC.
>>
>> This RFC proposes to change PHP's TLS constants to sane values. This
>> change
>> has been avoided by the pr
On 28 May 2017 22:23:30 BST, Dan Ackroyd wrote:
>Hi,
>
>I'd like to introduce an RFC to cleanup the behaviour of callables and
>related functions in PHP.
>
>https://wiki.php.net/rfc/consistent_callables
Hi Dan,
I like the principle behind this RFC, so thanks for tackling it. A few comments
came
Morning Internals,
I have updated the RFC to use a "min_signature_bits" setting instead.
Please share your thoughts.
https://wiki.php.net/rfc/distrust-sha1-certificates
Regards, Niklas
2016-11-26 16:49 GMT+01:00 Niklas Keller :
> Morning Internals,
>
> I plan to distrust SHA-1 certificates by
On Mon, May 29, 2017 at 9:48 AM, Niklas Keller wrote:
> Morning,
>
> I hereby open the vote on the "Improved SSL / TLS constants" RFC.
>
> This RFC proposes to change PHP's TLS constants to sane values. This change
> has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
> RFCs
On 28/05/2017 18:06, Aidan Woods wrote:
So, if I understand everything here correctly
```
interface Foo
{
public function bar(Boo $Boo);
}
```
and
```
interface Foo
{
/*
* @param $Boo, pretty please accept type Boo here
*/
public function bar($Boo);
}
```
will be equivalent i
Hi,
On Mon, May 29, 2017 at 12:28 PM, Stephen Reay wrote:
>
> Regarding the big change you suggest, making protected/private methods return
> false unless a new third parameter is true in is_callable():
>
> I think you need to make your intention a *lot* clearer under the "Private
> and protect
> On 29 May 2017, at 04:23, Dan Ackroyd wrote:
>
> Hi,
>
> I'd like to introduce an RFC to cleanup the behaviour of callables and
> related functions in PHP.
>
> https://wiki.php.net/rfc/consistent_callables
>
> Note, this RFC targets PHP 8, with soft deprecations in PHP 7.3 and
> deprecation
Am 29.05.2017 um 09:48 schrieb Niklas Keller:
Morning,
I hereby open the vote on the "Improved SSL / TLS constants" RFC.
This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better secu
Morning,
I hereby open the vote on the "Improved SSL / TLS constants" RFC.
This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with versi
34 matches
Mail list logo
