Re: [PHP-DEV] Re: [IDEA] allow extending enum

[Niklas Keller]

Am Mi., 29. März 2023 um 12:49 Uhr schrieb Rokas Šleinius :

> Sidenote, just asking :) was this expected behaviour that I had to
> analyse PHP source of the Docuwiki, create a new input field in
> the registration form named "spam" and fill it to gain a wiki
> username? Otherwise it would just keep expecting a different
> answer from me no matter what email I put in...
>

No, thanks for reporting. This should be fixed now.

Best,
Niklas

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Niklas Keller]

Hey Nikita,

I'd like to propose using HackerOne instead of bugs.php.net for security
issues: https://www.hackerone.com/company/open-source-community

Best,
Niklas

Am Di., 2. Nov. 2021 um 15:19 Uhr schrieb Nikita Popov :

> Hi internals,
>
> The migration from bugs.php.net to GitHub issues has already been
> discussed
> in https://externals.io/message/114300 and has already happened for
> documentation issues.
>
> I'd like to formally propose to use GitHub for PHP implementation issues as
> well: https://wiki.php.net/rfc/github_issues
>
> Regards,
> Nikita
>

Re: [PHP-DEV] intersection types and null for defaults, properties and return types

[Niklas Keller]

>
> > > > nicolas-grekas wrote on the PR:
> > > > > ?X cannot be confused with
> > > >
> > > > It confused me. A compiler might understand it, but as a human I have
> > > > trouble understanding it.
>

I think ?X would be a pretty poor syntax choice, as it's ambiguous as
many others said: (X|null)&(Y) vs. (X)|null.

What hasn't been proposed, yet, is ?X&?Y, so requiring either all or none
of the types being nullable.

Best,
Niklas

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

[Niklas Keller]

Hey all,

please remember that you can also use php -r to quickly evaluate
expressions, e.g. generating a random password:

php -r 'var_dump(bin2hex(random_bytes(16)));'

I'm in favor of removal without readline.

Best,
Niklas

Rowan Tommins  schrieb am Mi., 12. Mai 2021, 22:46:

> On 12/05/2021 17:21, Levi Morrison via internals wrote:
> >  The interactive shell requires libedit or readline support, which
> > this build does not have.
> >  Run php without -a to get an interactive mode instead.
>
>
> Unless I'm missing something, the default CLI mode (php without -a) is
> "interactive PHP" only if you consider "cat > foo.txt" to be an
> "interactive editor". You can type a complete script (remembering to
> start with " "end of file") and it will execute it, then exit.
>
> I too have been stung by accidentally triggering this mode without
> readline enabled, and would be happy to see Nikita's patch merged.
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

[Niklas Keller]

Sara Golemon  schrieb am Fr., 23. Apr. 2021, 00:21:

> On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller  wrote:
> >> Do you have a link to places where frameworks are doing this?  I built a
> >> contrived example which I think summarizes the behavior you described
> here:
> >> https://3v4l.org/6tunp
> >
> > I have links to a library / blog post:
> >
> > https://github.com/paragonie/password_lock
> >
> https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-bcrypt
> >
> > We're probably better off returning false for verify then instead of
> throwing? Hash could hash a random password instead if NUL bytes are
> present.
> >
>
> So this library (which I'd need convincing is widely used) doesn't
> actually have any null byte problems.
> Yes, the digest produced by hash(...,true) could have null bytes,
> but it's immediately piped into base64_encode() which papers directly over
> that issue producing only ascii printable output.
>

Scott knows what he's doing, so yes, this library isn't vulnerable nor did
I say that. It is rather an example of pre-encoding. People might remember
the approach incorrectly or have a similar idea themselves and make
mistakes in their own version of such code.

Best,
Niklas

>

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

[Niklas Keller]

Sara Golemon  schrieb am Do., 22. Apr. 2021, 17:27:

> On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller  wrote:
> > Thank you for your work. I think this is a really good safety check to
> have. I'd however go a step further and also throw on NUL in
> password_verify.
> >
> > You seem to assume that NUL bytes as input come from the end user, but I
> think it's more likely the developer uses a hash function with raw output
> as a pre-encoding, for reasons such as bringing long passwords below the
> bcrypt character limit.
> >
>
> I definitely am making the assumption you describe and it slightly
> horrifies me to learn that people are using a pre-digest (though I can
> understand why they would; ostensibly this should improve significance of
> the input bits).
>
> Do you have a link to places where frameworks are doing this?  I built a
> contrived example which I think summarizes the behavior you described here:
> https://3v4l.org/6tunp


I have links to a library / blog post:

https://github.com/paragonie/password_lock

https://paragonie.com/blog/2016/02/how-safely-store-password-in-2016#why-bcrypt


We're probably better off returning false for verify then instead of
throwing? Hash could hash a random password instead if NUL bytes are
present.

Best,
Niklas




>
> -Sara
>

Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT

[Niklas Keller]

Sara Golemon  schrieb am Do., 22. Apr. 2021, 03:47:

> I have this notion that we've discussed this before, I'm certain I knew
> that bcrypt wasn't binary safe, but someone reminded me that
> password_hash() could be called with null bytes in the password itself and
> that is just SCREAMING to have some safety-rails put on IMO.
>
> So I've thrown together https://github.com/php/php-src/pull/6897 to test
> that argon2 algos behave well (they do!), and modified the bcrypt algo to
> throw an exception if you try to hash a new password containing a null, but
> only warns if you've got a null when running password_verify().  My
> reasoning for the latter is because anyone trying to auth with a null
> character that succeeds does definitely know enough of the password to pass
> by simply not passing the null, so we shouldn't break existing users who
> already have hashes.  This only aims to break users who would otherwise be
> able to include a null, because they would have a false sense of security
> having their password truncated and can remedy that in their password
> choosing.
>

Hey Sara,

Thank you for your work. I think this is a really good safety check to
have. I'd however go a step further and also throw on NUL in
password_verify.

You seem to assume that NUL bytes as input come from the end user, but I
think it's more likely the developer uses a hash function with raw output
as a pre-encoding, for reasons such as bringing long passwords below the
bcrypt character limit.

Best,
Niklas

Since this does introduce a (small) break, I'm putting it to the list for
> opinions.
> If nobody objects, I'll merge this (8.1 only) at the end of the month.
>
> -Sara
>

Re: [PHP-DEV] wiki.php.net upgrade

[Niklas Keller]

Hey all,

the wiki is up to date now with the help of @Sergey Panteleev
. :-)

Sorry for the upgrade downtime being slightly longer than intended.

Best,
Niklas

Re: [PHP-DEV] wiki.php.net upgrade

[Niklas Keller]

Hey Sergey,

I've tried the same yesterday, but the auth plugin does no longer work for
me. I get a 404 after trying to sign in.

2692 files changed, 35365 insertions(+), 102210 deletions(-)

Dokuwiki changed a lot in the latest release, e.g. namespacing and
refactoring quite a bit. I'll need to have a look at the plugin.

@Stanislav Malyshev : We're only one release behind,
the other three yellow bars are about release candidates. However, Dokuwiki
might not be PHP 8 compatible, yet, at least the latest release only says
it fixes PHP 7.4 compatibility.

I'd be open to replace the wiki with a Git repository and markdown. I
prepared that a long time ago by writing a Dokuwiki -> Markdown converter.

The main challenges I see are:
 - Voting
 - Voting access for people without VCS account

Voting could probably be moved into main.php.net (except for people without
a VCS account, but we could probably approve an account there without any
further access?)

Best,
Niklas

Am Do., 8. Apr. 2021 um 11:16 Uhr schrieb Sergey Panteleev <
ser...@s-panteleev.ru>:

> Hi there!
>
> Oops .. for some reason an empty message came, try again =(
>
> I prepared an upgrade to the last release [1].
> I tested locally, it seems ok.
>
> Can we test it in the production environment, but not yet release it?
>
> [1] https://github.com/php/web-wiki/pull/15
>
> —
> wbr,
> Sergey Panteleev
>
>
> From: Joe Watkins 
> Date: Thursday, 8 April 2021, 11:23
> To: Stanislav Malyshev 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] wiki.php.net upgrade
> Any use case we have for content or collaboration is best served by
> whomever or whatever is going to secure that content or ability to
> collaborate.
>
> Nobody has updated the wiki in several years, despite warnings, and two
> very public breaches of security that we know about.
>
> We don't have the people to maintain our own infrastructure, let's stop
> pretending we do.
>
> Cheers
> Joe
>
> On Thu, 8 Apr 2021 at 08:15, Stanislav Malyshev 
> wrote:
>
> > Hi!
> >
> > > If we want to keep using wiki.php.net then, sure, we should update it.
> > > We could also migrate the wiki to GitHub.
> > >
> > > We also already have https://github.com/php/php-rfcs which we could
> use
> > > for RFCs instead of a wiki going forward.
> >
> > Wiki isn't used only for RFCs, there's more content there than that. I
> > personally think wiki serves these use cases much better than Github
> would.
> >
> > --
> > Stas Malyshev
> > smalys...@gmail.com
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

Hey all,

I've closed the vote and I'm happy to report that the RFC has been accepted
with 78.125% in favor (50:14).

I've moved the RFC to the landing state on
https://wiki.php.net/rfc#pending_implementationlanding

Thank you all for voting and taking part in the discussion!

I'll follow-up once the implementation is merged into core.

Best,
Niklas

Am Mo., 22. März 2021 um 21:08 Uhr schrieb Niklas Keller :

> >> I hope others would
>> >> play with it more as well if we had more time. Any objections?
>> >
>> > Yes, I object.
>> >
>> > You've been around PHP internals long enough to see the drama has
>> > occurred on other RFCs where people have been
>> > cajoled/pressured/threatened to either suspend votes or withdraw RFCs.
>> >
>> > Although this RFC is reasonably free from drama, I think it was wrong
>> > for you to ask for an extension regardless of the current voting. Not
>> > only is it improper on its face, but it sets a bad precedent for more
>> > drama filled RFCs.
>> >
>> > cheers
>> > Dan
>> > Ack
>> >
>> > btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
>> > all decisions that don't have an external time constraint), but
>> > changing the end time during the vote is bogus.
>>
>> I agree with Dan. Also, there was plenty of discussion time for this
>> RFC. It’s not like it was rushed.
>>
>
> Hey all,
>
> given the wording in the voting rules, the fact that the RFC hasn't been
> edited to include the new end date, and due to the objections, I think the
> best way forward is closing the voting on the RFC soon. Given no timezone
> is mentioned in the RFC, we can probably go with either UTC or UTC-12.
> We'll close the vote after UTC-12 passed.
>
> Please create a new thread for discussions about the voting rules in
> general that aren't specific for this RFC to keep this thread focused.
>
> Thanks,
> Niklas
>

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

>
> >> I hope others would
> >> play with it more as well if we had more time. Any objections?
> >
> > Yes, I object.
> >
> > You've been around PHP internals long enough to see the drama has
> > occurred on other RFCs where people have been
> > cajoled/pressured/threatened to either suspend votes or withdraw RFCs.
> >
> > Although this RFC is reasonably free from drama, I think it was wrong
> > for you to ask for an extension regardless of the current voting. Not
> > only is it improper on its face, but it sets a bad precedent for more
> > drama filled RFCs.
> >
> > cheers
> > Dan
> > Ack
> >
> > btw I would prefer that all RFC votes were longer (e.g. 4 weeks for
> > all decisions that don't have an external time constraint), but
> > changing the end time during the vote is bogus.
>
> I agree with Dan. Also, there was plenty of discussion time for this
> RFC. It’s not like it was rushed.
>

Hey all,

given the wording in the voting rules, the fact that the RFC hasn't been
edited to include the new end date, and due to the objections, I think the
best way forward is closing the voting on the RFC soon. Given no timezone
is mentioned in the RFC, we can probably go with either UTC or UTC-12.
We'll close the vote after UTC-12 passed.

Please create a new thread for discussions about the voting rules in
general that aren't specific for this RFC to keep this thread focused.

Thanks,
Niklas

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

Hey Levi,

On Mon, Mar 8, 2021 at 12:40 PM Aaron Piotrowski  wrote:
> >
> > Greetings everyone!
> >
> > The vote has started on the fiber RFC: https://wiki.php.net/rfc/fibers <
> https://wiki.php.net/rfc/fibers>
> >
> > Voting will run through March 22nd.
> >
> > Cheers,
> > Aaron Piotrowski
>
> This is selfish, but I would like to kindly request lengthening the
> voting window to allow me more time to play with it. I feel like I
> can't vote "yes" on something like this without more experience with
> it (which is why I currently have voted "no"). I hope others would
> play with it more as well if we had more time. Any objections?
>

How much time do you think you need?

I'd be open to an extension if others feel the same way, but I'm not sure
how much difference it makes given the RFC would currently pass also with
your no vote.

Best,
Niklas

>

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

Hey Josh,


> > This is a very valid concern to have. However, this code won't simply
> break if executed asynchronously.
> > It only breaks if the same method (or other methods making use of the
> same state) is executed concurrently on that object.
>
> I understand this, but of course this will be common in programs where
> fibers are used, and the nature of this proposal means that fibers
> will potentially be highly insidious and quite unpredictable in their
> reach.
>

Concurrent operations on stateful, mutable objects are certainly a risk and
concurrency shouldn't be introduced without thinking about the
consequences. Care must be taken if objects are used across different
fibers concurrently, unless you use global state, then you'll have a harder
time adding concurrency to your application.


> > If you can see the race condition here, you can probably also see the
> race condition in the original snippet above.
>
> The difference is that in the second case, the developer has
> *explicitly opted into the underlying call being async*. I.e. they
> expect it, and can design with it in mind.
>

While the developer opted into async / non-blocking I/O, they still might
not have thought about concurrent operations on that same object.

> Being able to use the type system is a concern the RFC solves, but that's
> rather just nice-to-have. The relevant problem is the call stack pollution
> or "What color is your function" problem. It simply doesn't make sense for
> applications and libraries to offer an async and non-async interface for
> everything. Due to the "What color is your function" problem, there can't
> be a gradual migration to non-blocking I/O, which will mostly result in
> non-blocking I/O simply not being supported by the majority of libraries,
> making it basically non-viable in PHP.
>
> Perhaps we could rather make fibers *opt in* at the *callsite*
> (similar to goroutine calls) in order to prevent functions
> unexpectedly being executed asynchronously due to faraway changes.
> This would be safe and predictable while also avoiding the "What color
> is your function" problem. For example
>
> private function capturePayment(): void
> {
> $paymentRequest = preparePaymentRequest($this->currentOrder);
> // allow, but don't require, the underlying call to use
> fibers. Callers higher up the stack would also have to opt in
> async $this->paymentGateway->capturePayment($paymentRequest);
>
> $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
> }
>
> With this approach, APIs we'd avoid the "what colour is your function"
> problem without sacrificing the safety that we really need in e.g.
> ecommerce.
>

This doesn't really avoid the "what color is your function" problem, as
you'd have to mark all function calls with "async" then, eventually
resulting in every PHP function call having to be prefixed with "async".

Rather than marking methods with "synchronized" as mentioned before, it
might be more feasible to mark methods with a keyword if they allow
concurrent operations. I'll have to research which options are viable.

Best,
Niklas

Re: [PHP-DEV] [VOTE] Fibers

[Niklas Keller]

Hey Josh,


> Apologies, this is a long one!
>
> This RFC strikes me as being very dangerous. Implicitly allowing code
> which is synchronous by design to be executed asynchronously seems
> sure to lead to very subtle, unpredictable, confusing and dangerous
> bugs.
>

Thank you for sharing your thoughts, I'll respond inline for better
context, but shortened some paragraphs for better readability.


> [...]
>
> For example, the PHP ecosystem is full of code like this:
>
> private function capturePayment()
> {
> $paymentRequest = preparePaymentRequest($this->currentOrder);
> $this->paymentGateway->capturePayment($paymentRequest);
>
> $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
> }
>
> In the above code snippet, the developer has relied on the fact that
> the mutable value $this->currentOrder will be the same before and
> after the call to $this->capturePayment() [...]
>

This is a very valid concern to have. However, this code won't simply break
if executed asynchronously.
It only breaks if the same method (or other methods making use of the same
state) is executed concurrently on that object.


> [...]
>
> - These race conditions will cause problems so rarely that developers
> will not even realise that their programs contain dangerous bugs. [...]
> - Changes very, very far away from your code can cause your code to
> become unexpectedly asynchronous. [...]
> - As a library author, there is no way of knowing how your code is
> going to be used, and what injected dependencies might use fibers
> internally.
>
> The counter arguments:
> - "The above code snippet is suboptimal, it shouldn't assume that
> mutable state remains unchanged following some IO, and the order
> should be passed in as an arg." [...]
> - "Fibers should only be enabled in async first programs." and "We
> could flag that certain libraries are fiber compatible or
> incompatible." [...]
>
> Consider the following:
>
> private async function capturePayment()
> {
> $paymentRequest = preparePaymentRequest($this->currentOrder);
> await $this->paymentGateway->capturePayment($paymentRequest);
>
> $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
> }
>
> Looking at the above code, I can see the race condition. It becomes
> explicit. So I change the code and communicate explicitly via the type
> system that this function is asynchronous and that my code expects
> PaymentGateway::capturePayment() to be asynchronous.
>

If you can see the race condition here, you can probably also see the race
condition in the original snippet above.

The overall issue you're describing is thread safety and mutable state. It
exists with fibers, but a very similar issue exists with explicit async /
await.
Just because something supports asynchronous I/O, doesn't mean it also
supports concurrent operations on its state.

It might be a good idea to introduce some guarding concept in a follow-up
RFC, so objects can easily protect against being used concurrently e.g.

```
private synchronized function capturePayment()
{
 $paymentRequest = preparePaymentRequest($this->currentOrder);
 $this->paymentGateway->capturePayment($paymentRequest);

 $this->currentOrder->setTransactionId($paymentRequest->getTransactionId());
 }
```

"synchonized" isn't the right keyword here, but I can't think of a better
name right now.


> Regarding PHP's type system not supporting generics, and the
> associated advantages of this RFC over promises; I agree that this is
> a problem with promises. But the lack of generics in PHP already means
> we have no language-level type safety on data structures, which is
> certainly worse than not having type safety on promises. Psalm et al
> have provided reasonable solutions to this issue.
>

Being able to use the type system is a concern the RFC solves, but that's
rather just nice-to-have. The relevant problem is the call stack pollution
or "What color is your function" problem. It simply doesn't make sense for
applications and libraries to offer an async and non-async interface for
everything. Due to the "What color is your function" problem, there can't
be a gradual migration to non-blocking I/O, which will mostly result in
non-blocking I/O simply not being supported by the majority of libraries,
making it basically non-viable in PHP.

Best,
Niklas

Re: [PHP-DEV] [RFC] Fibers

[Niklas Keller]

Hey Nikita,

Thank you for the proposal. Ergonomics of async I/O in PHP certainly leave
> something to be desired right now, and improvements in this area are
> welcome.
>
> Despite your explanations in the RFC and this thread, I'm still having a
> hard time understanding the purpose of the FiberScheduler.
>
> My current understanding is that the FiberScheduler is a special type of
> fiber that cannot be explicitly scheduled by the user -- it is
> automatically scheduled by Fiber::suspend() and automatically un-scheduled
> by Fiber::resume() or Fiber::throw(). It's the fiber that runs between
> fibers :) Does that sound accurate?
>

Yes, that's accurate. Fibers are used for cooperative multi-tasking and
there's usually a single scheduler responsible for the scheduling. Multiple
schedulers would block each other or busy wait. So having multiple
schedulers is strongly discouraged in long running applications, however,
it might be acceptable in traditional applications, i.e. PHP-FPM. In
PHP-FPM, multiple schedulers partially blocking each other is still better
than blocking entirely for every I/O operation.


> What's not clear to me is why the scheduling fiber needs to be
> distinguished from other fibers. If we want to stick with the general
> approach, why is Fiber::suspend($scheduler) not Fiber::transferTo($fiber),
> where $fiber would be the fiber serving as scheduler (but otherwise a
> normal Fiber)? I would expect that context-switching between arbitrary
> fibers would be both most expressive, and make for the smallest interface.
>

There are a few reasons to make a difference here:

- SchedulerFibers are run to completion at script end, which isn't the case
for normal fibers.
- Terminating fibers need a fiber to return to. For schedulers it's fine if
a resumed fiber terminates, for normal fibers it should be an exception if
the scheduler fiber terminates without explicitly resuming the suspended
fiber.
- Keeping the previous fiber for each suspension point is complicated if
not impossible to get right and generally complicates the implementation
and cognitive load, see following example:

main -> A -> B -> C -> A (terminates) -> C (previous) -> B (terminates) ->
C (previous, terminates) -> main

In the example above, the previous fiber linked list from C back to main
needs to be optimized at some point, otherwise A and B need to be kept in
memory and thus leak memory until C is resumed.

I'm sure Aaron can present a few other reasons to keep the separation.


> The more limited alternative is to instead have Fiber::suspend() return to
> the parent fiber (the one that resume()d it). Here, the parent fiber
> effectively becomes the scheduler fiber. If I understand right, the reason
> why you don't want to use that approach, is that it doesn't allow you to
> call some AMP function from the {main} fiber, create the scheduler there
> and then treat {main} just like any other fiber. Is that correct?
>

Correct, this wouldn't allow top-level Fiber::suspend(). It would also make
the starting / previously resuming party responsible for resuming the fiber
instead of the fiber being able to "choose" the scheduler for a specific
suspension point. One fiber would thus be effectively limited to a single
scheduler.

Best,
Niklas

Re: [PHP-DEV] Straw poll: Naming for `*any()` and `*all()` on iterables

[Niklas Keller]

>
> I want to re-iterate my opinion on this discussion thread: anything
> with a prefix is a hard-no from me. Namespaces are literally designed
> for this, and I will not vote "yes" to `iter_all`, `iterable_all`,
> etc, no matter what the prefix is. Anything without a namespace is a
> no from me.
>
> I'm flexible on many other points, but not this one. It's 2020 (almost
> 2021); let's use namespaces for what they were designed for. This is a
> perfect opportunity; they work on more than just arrays so using the
> `array_` prefix for consistency doesn't apply.
>

Hey Levi,

while I agree that namespaces were designed for this, I think `all` and
`any` are too generic names, even in a namespace.

I think Java's naming with any_match / all_match could be a good fit.

If promises / futures make it into core in the future, there will be a need
for an `any` / `all` function combining promises / futures.

Maybe these should be named `array_*` and all array functions should be
adjusted to work with iterators?

Best,
Niklas

Re: [PHP-DEV] Re: HTTP/1.1 by default in PHP 8.0

[Niklas Keller]

Hey all,

>
> > Given that it's a very small change, the RFC is probably not necessary,
> in
> > which case it's not too late, however I'd like some clarification about
> > what this actually offers over defaulting to 1.0.
>

One thing it offers is detecting truncated responses. Servers will often
respond without transfer-encoding: chunked / content-length for an HTTP/1.0
request, which leaves connection closure as only indication where the
response ends.

As we progress to HTTP/3 already, newer implementations might not implement
1.0 at all. If we're compatible with 1.1 already, there's no reason IMO not
to advertise and use its features.

That's a very reasonable question. The way I see it is this:
>
> The risk of advertising 1.0 by default is that some software will have been
> programmed to outright refuse that protocol version. I don't know of any
> recent examples, but this bug report from 2007 was for a SOAP endpoint that
> returned 505 Version Not Supported: https://bugs.php.net/bug.php?id=43069
> Notably, Dmitry's patch for that bug made sure the protocol context option
> is honoured by ext/soap, but also specifically defaulted it to HTTP/1.1 as
> of PHP 5.3.
>
> The risk of advertising 1.1 by default is that some software will respond
> with a more complex response, and trigger some bug in our response parsing.
> This was previously the case with detecting "Transfer-Encoding: chunked"
> headers, for instance. By advertising 1.0, we may be benefitting from
> servers "downgrading" their response.
>

Do we handle 1XX responses, yet?
https://tools.ietf.org/html/rfc7231#section-6.2


> In practice, a large amount of software appears to do neither, and simply
> replies with an HTTP/1.1 response to a HTTP/1.0 request. This is why I talk
> about "advertising" versions - in practice, the code is always acting as an
> HTTP/1.1 client, e.g. sending "Connection: Close", and listening for
> Transfer-Encoding, because it's increasingly rare for a server to actually
> honour the 1.0 spec.
>

This is what implementations should do, see
https://tools.ietf.org/html/rfc7230#section-2.6

That section also says we should send 1.1, as we support it.

Best,
Niklas


> My main motivation for the change is that if someone was writing the
> feature today, I don't think it would occur to them to default to 1.0, and
> I think _new_ users would be less surprised at needing to opt into 1.0 than
> into 1.1.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] VCS Account Request: ondrejmirtes

[Niklas Keller]

Am Sa., 11. Juli 2020 um 08:04 Uhr schrieb Kalle Sommer Nielsen <
ka...@php.net>:

> Hi
>
> Den lør. 11. jul. 2020 kl. 08.55 skrev Ondřej Mirtes :
> > Oh, thank you. Should I fill out this form?
> https://wiki.php.net/?do=register
>
> Yes that is the one. Someone with wiki admin karma needs to grant you
> the right write permission once that is done. When you have
> registered, then send off an email similar to the VCS from this thread
> (state your wiki username and intentions) to the internals mailing
> list.
>
> > What email should I use for the "To which email address do you have to
> send an email to now?" field?
>
> This should be the internals mailing list address. The information to
> fill out this spam challenge seems to have been lost sometime when we
> upgraded the wiki software but never fixed.
>

Fixed. :-)

Re: [PHP-DEV] Graceful timeout

[Niklas Keller]

Hey David,

I guess you're looking for a preemptive timeout. I guess an alarm signal
and PHP's async signal handling will be your best bet here.

In case you're looking for a cooperative timeout, https://amphp.org/ and
it's `Amp\Promise\timeout()` / `TimeoutCancellationToken` might be helpful.

Best,
Niklas

Am Sa., 16. Mai 2020 um 19:41 Uhr schrieb David Rodrigues <
david.pro...@gmail.com>:

> Hello!
>
> Currently we can use set_time_limit() to specify that our script will run
> by some seconds before we get "fatal error: maximum execution time of 1
> second exceeded". And we can't catch it and keep running.
>
> I believe that it is interesting to create a function that is able to limit
> processing and stop when the time limit is recovered.
>
> $completeRun = set_time_limit_callback(function () {
> sleep(2);
> }, 1);
>
> var_dump($completeRun);
>
> Where $completeRun will be TRUE only if callback could run until it
> returns, and FALSE if timeout.
>
> It should be very useful when we need works with external resources, like
> RESTful, where timeout can occur and we need a better way to work with
> that. Or when we have few seconds to run a process.
>
> What do you think?
>
>
> Atenciosamente,
> David Rodrigues
>

Re: [PHP-DEV] Deprecating uniqid()

[Niklas Keller]

Rowan Tommins  schrieb am Mo., 4. Mai 2020, 10:59:

> On Mon, 4 May 2020 at 06:27, Andreas Heigl  wrote:
>
> >
> > As replacement I could think of showing people the way to UUIDs.
> >
>
>
> Although the name sounds similar, I don't think UUID would be a good
> replacement for uniqid(). In my experience, it's used for things like
> generating ID attributes for HTML elements, or suffixes for table names, or
> even file names; applications that really just need a few alphanumeric
> characters that are different each time.
>

Seems like UUIDs would be a good fit for all of these.

>
> > As the function itself was never intended for cryptographically secure
> > values I would not see random_* functions or the like as a replacement.
> >
>
>
> Firstly, while everyone *should* understand the phrase "cryptographically
> secure", I don't think most users do. Despite the warning in the manual, I
> would put money on people using uniqid() for things that really should use
> "strong" randomness.
>
> Secondly, is there actually a *disadvantage* to using cryptographically
> secure randomness when you don't need it? Speed? There's no advice in the
> manual for random_int or random_bytes saying *not* to use them, and their
> names seem deliberately chosen to imply they are the go-to functions for
> randomness.
>
> The only downside I can see suggesting something like random_string(13,
> '0-9a-f') as a direct replacement for uniqid() is that without a time input
> it might happen to generate the same string twice in a request. On the
> other hand, uniqid actually disclaims any guarantee of uniqueness anyway.
>

UUIDs have enough length to make collisions practically irrelevant, so
again, they seem to be the best replacement.

Best,
Niklas

Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] Deprecating uniqid()

[Niklas Keller]

Hey Allen,

there's been discussion on whether we should deprecate or replace its
functionality. Without changing the output format, it's impossible to
have enough entropy.

Without consensus on the best way forward, I've just never cared to
put this to a vote.

I'll happily collaborate on moving this RFC forward for PHP 8.

Best,
Niklas

Am Sa., 2. Mai 2020 um 20:57 Uhr schrieb AllenJB :
>
> Hi all,
>
> I'd like to discuss deprecating uniqid()
>
> I believe it's dangerously bad a doing "what it says on the tin". New
> developers still reach for it and do not read the warnings on the manual
> page (or if they do, don't fully understand how bad it is).
>
> For older codebases that still rely on it, a userland replacement can be
> easily implemented (and could be published on Packagist).
>
> I noticed there was an RFC [0][1] brought up 2 years ago, but was never
> voted on. Does anyone know why this was?
>
> [0] https://externals.io/message/102097
> [1] https://wiki.php.net/rfc/deprecate-uniqid
>
> Is there interest in deprecating this function?
>
> If not deprecation, how could it be (further) "improved"? My first
> thought is to make the "more entropy" option enabled by default (the
> argument could remain so that it can be disabled by codebases that rely
> on the lower length and can take the tradeoffs).
>
> AllenJB
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

[Niklas Keller]

Hey Benas,

a question has come up whether we even need the PhpAttribute /
Attribute attribute at all. We could prevent any conflict if we just
delete it.

Best,
Niklas

Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML
:
>
> Hey internals,
>
> Since it's safe to say that the Attributes v2 RFC has passed, I wanted to
> make a separate thread based on the comment by Rowan Tommins in the PHP
> namespace policy thread. This is a quote from his comment:
>
> > One prefix doesn't make a trend. "PhpToken" is a different case - it's a
> > token of PHP source code, so the prefix isn't anything to do with
> > avoiding name collisions, it's a natural clarification.
> >
> > To be honest, I'd be perfectly happy with the attributes RFC using the
> > class name "Attribute", just as we use "Iterator", "Closure",
> > "Exception", etc, etc. At which point the whole thing's a non-issue.
>
> I do strongly agree with him and I believe we should rename `\PhpAttribute`
> to simply `\Attribute` before the PHP 8 release in order to improve
> consistency with other classes and interfaces e. g. Iterator, ArrayAccess,
> Countable. It would also make the attribute class definition look more
> aesthetically pleasing:
>
> ```
>  <>
> class Test {}
> ```
>
> I am ready to make an RFC for this if the replies are mostly positive, so
> please, express your opinions!
>
> Best regards,
> Benas Seliuginas
> P.S: this is my second email account so hopefully it won't get marked as
> spam.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Renaming PhpAttribute to Attribute

[Niklas Keller]

Hey Benas,

I've also tried to get that change into the original RFC, but wasn't able to.

I'm in favor of an amendment RFC to change the name to Attribute.

Best,
Niklas

Am Di., 28. Apr. 2020 um 17:37 Uhr schrieb Benas IML
:
>
> Hey internals,
>
> Since it's safe to say that the Attributes v2 RFC has passed, I wanted to
> make a separate thread based on the comment by Rowan Tommins in the PHP
> namespace policy thread. This is a quote from his comment:
>
> > One prefix doesn't make a trend. "PhpToken" is a different case - it's a
> > token of PHP source code, so the prefix isn't anything to do with
> > avoiding name collisions, it's a natural clarification.
> >
> > To be honest, I'd be perfectly happy with the attributes RFC using the
> > class name "Attribute", just as we use "Iterator", "Closure",
> > "Exception", etc, etc. At which point the whole thing's a non-issue.
>
> I do strongly agree with him and I believe we should rename `\PhpAttribute`
> to simply `\Attribute` before the PHP 8 release in order to improve
> consistency with other classes and interfaces e. g. Iterator, ArrayAccess,
> Countable. It would also make the attribute class definition look more
> aesthetically pleasing:
>
> ```
>  <>
> class Test {}
> ```
>
> I am ready to make an RFC for this if the replies are mostly positive, so
> please, express your opinions!
>
> Best regards,
> Benas Seliuginas
> P.S: this is my second email account so hopefully it won't get marked as
> spam.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] Re: [RFC] Attributes v2

[Niklas Keller]

Hey Benjamin,

thanks for your answers!

> <> would best require a namespace (PHP\Attributes) as I feel
> claminig "Attribute" class in the main namespace might cause problems for
> users.

While this is true, I don't see how Attribute is different to any
classes introduced in the "recent" versions like \Generator or \Error.
Maybe Nikita can run his analyzer to see how widespread its usage is?

> But there is no PHP namespace yet and proposals about this have just
> gotten to the list. I have therefore looked to PhpToken from nikitas recent
> RFC as an example for naming, because several contributors mentioned that
> the PHP\Attributes namespace I suggested in an earlier version of the RFC
> would be an instant "no" vote, because of the lack of previous decision on
> this topic.

Some prefix is pretty similar to a namespace, and I don't like a new
naming convention being part of this RFC. For PhpToken the naming
might make sense, as "Token" alone might be seen as a too generic
term.

> The reason these are plain PHP objects and not some special case is that
> you can re-use them for configuration from different sources. Symfony
> Validator is a good example where the "attributes" could map to the
> validator configuration classes that are also used from XML, YAML, ...

Sounds fine!

> Yes, INSTANCE_OF attempts to load each attributes class, but if an
> attribute class cannot be looked up (not autoloadable) it gets skipped
> without error (subject to error handling of autoloader implementation, but
> for Composer it skips).

This seems rather strange to me, but I can definitely see the value if
you're using no-dev deployments, for example. I think I'd be better to
disallow inheritance for attributes and skip the autoloading and
INSTANCE_OF parameter here.

> >
> > I expect annotations to be readonly, which classes as outlined in the
> > RFC cannot currently enforce in PHP. A syntax similar to interfaces
> > might be appropriate, I'm not sure whether that has been discussed:
> >
>
> The write-once / readonly RFC was rejected and only internal classes can
> implement this behavior (see ext/dom). But userland attributes also map to
> userland classes, so as you say this is not possible. However given this
> RFC maps to existing concepts.

I'd be possible if the actual objects are created in core and userland
only provides the contracts (interfaces) for these attributes.

> I don't see how preventing instantiation or requiring readonly in userland
> produces any benefits over this described use-case in the RFC. This would
> make attributes much stricter than everything else in the language, I don't
> see how its fair to impose this on a new feature like Attributes, when the
> language doesn't even have concepts for this strictness for regular classes
> (containing more important code). Mapping to "normal" classes is the way C#
> implements attributes, I don't think this should be more complex than that.

Readonly is just something I'd like to see, it's not a requirement and
I'll still vote yes if the more important points are solved.

What's more important here IMO is the restriction of inheritance,
mainly because the raw arguments are exposed via reflection and won't
be compatible between parent and child attribute in any case.

There are a few options I see to solve this:

 - Require constructor compatibility for attribute classes (only other classes)
 - Forbid extending attribute classes entirely
 - Remove getArguments() from reflection

I think my preferred solution would be to forbid inheritance, because
that also solves the autoloading inconsistencies (given that
implemented interfaces aren't respected in
`ReflectionFunction::getAttributes()` and others.

> Extensions, and Third Party library authors can easily guard their
> attribute classes against writes from the outside with the usual OOP
> abstractions and if application authors deem their attributes to be
> writable that is their business.

That's probably fine, yes, if `getAsObject()` / `toObject()` /
`createObject()` always returns a new object.

> Named parameters might some day come to PHP in the future, and this is
> precisely the argument for treating an attribute like a regular php class
> with a constructor, because the named params syntax would look exactly the
> same in attribute declarations then, increasing language consistency.
>
> The reason I went with the C# way of mapping to a "plain class" is
> simplicity. The concept of attributes is already not the easiest nut to
> crack, inventing another keyword and a structure that looks like a class,
> but has very different implications requires a lot of words in the
> documentation and doesn't provide the easiest access to beginners.

I guess writing your own annotations and processing them isn't a
beginners topic, but using them to attribute code definitely is.

> >
> > Finally, the naming of "getAsObject" should IMO be improved,
> > especially if I read the RFC correctly and autoloading 

Re: [PHP-DEV] Re: [RFC] Attributes v2

[Niklas Keller]

Hey Benjamin,

I haven't really followed the discussion, so sorry if anything I'm
writing has already been discussed.

Attributes / annotations are one of the two things I currently miss
most in PHP (the other being generics), so thanks for the work on
that!

There are a few points that seem odd to me, I'll start with the "Php" prefix:

```php
>
class SingleArgument
{
public $value;

public function __construct(string $value)
{
$this->value = $value;
}
}
```

I think this should be <> instead, if we go with that
syntax. However, I'd even propose another syntax, as attributes aren't
ordinary classes, I'm not sure whether they should be instantiatable
from userland and / or be able to use inheritance, especially as
constructors in PHP aren't subject to variance rules. I guess the
INSTANCE_OF filter also changes whether the attributes are autoloaded
or not?

I expect annotations to be readonly, which classes as outlined in the
RFC cannot currently enforce in PHP. A syntax similar to interfaces
might be appropriate, I'm not sure whether that has been discussed:

```php
:
>
> As there has only been minimal new discussion after the last changes to the
> RFC I wanted to give a heads up that I will open the vote on Monday
> afternoon.
>
> If you have further remarks or questions about the RFC, please let me know.
>
> On Mon, Mar 9, 2020 at 3:42 PM Benjamin Eberlei  wrote:
>
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2
> >
> > A working patch is at https://github.com/beberlei/php-src/pull/2 though
> > work around the details is still necessary.
> >
> > The RFC contains a section with common criticism and objections to
> > attributes, and I hope to have collected and responded to a good amount
> > already from previous discussions.
> >
> > There is also a fair amount of implementation detail still up for debate,
> > which is noted in "Open Issues". I have pre-committed to one approach, but
> > listed alternatives there. On these issues I am looking for your feedback.
> >
> > greetings
> > Benjamin
> >

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

Re: [PHP-DEV] Re: Changing the generated name for anon classes

[Niklas Keller]

Hi Nikita,

while we're changing the naming scheme, could we also get rid of the
NUL byte, please? Binary in logs due to things like get_class really
isn't that nice.

Regarding checking whether something is an anonymous class, how about
adding a function to check whether a class name is an anonymous class?
Something like is_anonymous_class(get_class($obj));

Best,
Niklas

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

[Niklas Keller]

> Hi Internals,
>
> After a couple of years of incubation, I am happy to offer a second version 
> of this RFC:
>
>   https://wiki.php.net/rfc/request_response
>
> It proposes an object-oriented approach around request and response 
> functionality already existing in PHP, in order to reduce the global-state 
> problems that come with superglobals and the various response-related 
> functions.
>
> The SQLite "about" page says, "Think of SQLite not as a replacement for 
> Oracle but as a replacement for fopen()."  
>  Likewise, think of this RFC not as a replacement for HttpFoundation or 
> PSR-7, or as a model of HTTP messages, but as an object-oriented alternative 
> to superglobals, header(), setcookie(), setrawcookie(), and so on.
>
> Thanks in advance for your time and consideration while evaluating it.

Hey Paul,

I think the request / response API is entirely fine being solved in
userland instead of in php-src. However, since you already made such a
proposal, I want to give some feedback:

Naming

I think we shouldn't take over the naming of the super globals, e.g.
$_GET really contains the query parameters and has nothing to do with
GET or POST, so $request->getQueryParameter(...) would be a better
name.

Type Safety

I think the API should be type safe. Currently $request->get['key']
can be null | string | string[] | ... Most parameters only appear a
single time, so a method returning the first parameter value or null
could be used instead.

API Issues

I don't see any reason to keep specials such as
$_SERVER['HTTP_X_REQUESTED_WITH'] vs. $request->requestedWith, which
is just another HTTP header.

If there's $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'] => $request->method
and $_SERVER['REQUEST_METHOD'] => $request->method, how can I get the
original  (actual) method?

Given 'echo $content; => $response->setContent($content);', shouldn't
this rather be something like `addContent()`? How does streaming
responses work? There's ServerResponseSender, but I think this should
be part of the Response API.

The Request object should be mutable, e.g. you might want to change
the client IP to be based on a x-forwarded-header instead of the TCP
source address.

Other Commentary

> A: It supports async exactly as much as PHP itself does.

Not really. PHP has built-in stream_select / non-blocking streams, so
supports the tools required for async out of the box.

Regards, Niklas

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

Re: [PHP-DEV] Warn when declaring required parameter after optional one

[Niklas Keller]

Hi Nikita,

while this is a rather small change, it has quite some BC impact, as
not all old code has been adjusted to run on PHP 7.1+ only using
nullable types.

I'd like to see an RFC with a vote for this.

Regards,
Niklas

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

Re: [PHP-DEV] fdiv() function

[Niklas Keller]

Hi Nikita,

> The fdiv() function will perform a floating-point division while treating
> division by zero as a perfectly legal operation, and will not emit any kind
> of diagnostic in that case. Instead it will return the INF/-INF/NAN result
> mandated by IEEE-754. It mirrors the existing fmod() function.

I'd prefer floatdiv() as name matching intdiv(), but wasn't aware
fmod() is already a thing. So now I think fdiv() might be the slightly
more consistent name.

Regards, Niklas

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

Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

[Niklas Keller]

> Maybe it would be good to add a secondary vote to decide if this should be
> implemented in PHP 7.4 or PHP 8.

Missed that, it should definitely target PHP 8, not 7.4.

Regards, Niklas

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

Re: [PHP-DEV][RFC] Normalize array's "auto-increment" value on copy on write

[Niklas Keller]

Hi Wes,

I don't think it'll work the way you described. I think we have to
make the auto-increment value be entirely dependent on the values in
the array for it to work.

Consider the following example combining your initial assertion in the
RFC with an example further down:

```
https://3v4l.org/vDj4c

In that case `$array` isn't reset by COW because it's not copied and
the initial assertion doesn't pass anymore.

Regards, Niklas

Am Do., 20. Juni 2019 um 09:36 Uhr schrieb Nikita Popov :
>
> On Thu, Jun 20, 2019 at 1:45 AM Wes  wrote:
>
> > Hello internals, I just published another RFC
> >
> > https://wiki.php.net/rfc/normalize-array-auto-increment-on-copy-on-write
> >
> > Please keep in mind that my intentions are good and I am proposing things
> > in the interest of everybody. Also, I am aware that I might be wrong. If I
> > am, please illustrate the reason without barking at me. Thanks <3
> >
>
> Looks reasonable to me.
>
> Nikita

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

Re: [PHP-DEV] open_basedir?

[Niklas Keller]

> > That's exactly the reason why I'm for removing it. There will always
> > be ways to circumvent open_basedir and setups like this are insecure.
> > It gives a false sense of security. It's not better than nothing,
> > because most hosting providers would opt for a real solution instead
> > of leaving users entirely unprotected.
>
> What's your solution then? I'll be more than happy to have anything
> better that will work with thousands of users :)

Solutions that work at the OS level have been suggested in this
thread. It's not my job figuring out a solution that works better for
your business at scale.

> Also I don't get the argument that because it isn't perfect it would
> not be useful. It definitely is, as a security measure.

Quoting https://www.php.net/security-note.php:

> For Local exploits we mostly hear about open_basedir or safemode problems on 
> shared virtual hosts. These two features are there as a convenience to system 
> administrators and should in no way be thought of as a complete security 
> framework. With all the 3rd-party libraries you can hook into PHP and all the 
> creative ways you can trick these libraries into accessing files, it is 
> impossible to guarantee security with these directives. The Oracle and Curl 
> extensions both have ways to go through the library and read a local file, 
> for example. Short of modifying these 3rd-party libraries, which would be 
> difficult for the closed-source Oracle library, there really isn't much PHP 
> can do about this.

The exact issue is that it appears to be good enough, but it really isn't.

> chroot isn't perfect either, but you might want to use it as well.
>
> Same for disable_functions, sure there will be ways to go around it,
> but it will still block 90% of attacks we might get. So, definitely not
> the most reliable thing, but it adds a layer that may help.
>
> I can pick the lock on my front door in about 10 minutes, a
> professional probably much less. And you can enter by breaking a window.
> But it is still effective as a security measure. And it would be silly
> if someone would come and tell me that the lock should be removed
> because it gives a false sense of security :)

My hope is that if we remove the feature, hosting providers will opt
for a proper door instead of one made from paper.

Regards, Niklas

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

Re: [PHP-DEV] PHP header files, restrict to declaring code only

[Niklas Keller]

Instead of introducing a declare option or special open tag, how about
another "include" construct, that only allows side-effect free (apart
from class loading) operations?

e.g. "require_noexec 'foobar.php'"

Regards, Niklas

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

Re: [PHP-DEV] open_basedir?

[Niklas Keller]

> I'm against deprecating it or removing it.
>
> As said earlier, it has some security value, especially with mass
> hosting. If I'm hosting thousands of websites for thousands of users,
> using chroot is not doable, and open_basedir is a good alternative (at
> least it's better than nothing).
>
> That's why it's used by ISPconfig and other panels: there is no other
> solution that I know of.

That's exactly the reason why I'm for removing it. There will always
be ways to circumvent open_basedir and setups like this are insecure.
It gives a false sense of security. It's not better than nothing,
because most hosting providers would opt for a real solution instead
of leaving users entirely unprotected.

Regards, Niklas

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

Re: [PHP-DEV] open_basedir?

[Niklas Keller]

Am Di., 7. Mai 2019 um 12:11 Uhr schrieb Nikita Popov :
>
> Hi internals,
>
> The open_basedir ini setting has two significant problems:
>
> 1. It is a major performance hit, because it disables the realpath cache.
>
> 2. Many people think it is a security feature and use it as such. However,
> open_basedir is in reality a "best effort" mechanism, with known
> workarounds and more regularly being found. Especially when it comes to
> interactions with 3rd party libraries, enforcing open_basedir is simply
> impossible.
>
> What open_basedir tries to do must be implemented on the operating system
> level to work reliably (and of course such mechanisms exist, such as jails,
> chroot and friends).
>
> I wonder if it is feasible to drop this ini setting? Enforcing this doesn't
> really seem like any of PHP's business. If not, I think we need to at least
>
> a) make it clear in the documentation that this is *not* a security option
> and only exists to prevent "accidents" and
> b) update the security policy (https://wiki.php.net/security) to state that
> open_basedir bypasses are not security issues. I believe this has been part
> of Debian's security policy for some time already.
>
> Regards,
> Nikita

Hi Nikita,

I'm probably in favor of removing it. If it is used for unit tests to
check file access outside some directory, we could maybe allow it to
be set by code only but not by php.ini?

If we decide to remove it in PHP 8, we should probably trigger a fatal
startup error in case it is configured in php.ini to prevent loosing
the protection entirely for people relying on it.

Regards,
Niklas

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

Re: [PHP-DEV] [RFC] [Vote] Change the precedence of the concatenation operator

[Niklas Keller]

Hey Bob,

in the RFC you mention:

> While this is a subtle behavior change in that it will give different outputs 
> without notice or warning, it is trivially possible to statically analyze the 
> code and find all instances where this happens.

On the other hand, there's:

> PHP 8, with a deprecation notice in PHP 7.4 upon encountering an 
> unparenthesized expression containing an '.' before a '+' or '-'.

So there will be a notice if the second vote passes and the output
changes in PHP 7.4.

Regards, Niklas

Am Mi., 1. Mai 2019 um 00:41 Uhr schrieb Bob Weinand :
>
> Hey,
> As announced yesterday, I'm now starting the vote on this RFC.
>
> I'm confident that the impact is really that minimal that a relatively quick 
> deprecation and change path is preferred.
>
> https://wiki.php.net/rfc/concatenation_precedence
>
> The vote ends on May 15.
>
> Thanks,
> Bob
>

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

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Niklas Keller]

Am Mo., 29. Apr. 2019 um 09:03 Uhr schrieb Bob Weinand :
>
>
> Am 25.04.2019 um 11:52 schrieb Nikita Popov 
> mailto:nikita@gmail.com>>:
>
> On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand 
> mailto:bobw...@hotmail.com>> wrote:
> Hey,
>
> I feel like concatenation having the same precedence than addition and 
> subtraction is promoting programmers to make mistakes. Albeit typically easy 
> to catch ones, it is a quality of life change at least.
>
> Hence I'm proposing a RFC changing the precedences:
> https://wiki.php.net/rfc/concatenation_precedence
>
> Bob
>
> Similarly to the ternary associativity RFC, I've analyzed the top 2000 
> composer packages and checked whether they would be affected by this change: 
> https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa
>
> The tl;dr is that there were 5 instances where behavior would change per this 
> RFC, and all 5 of them are bugs in current code and would be interpreted 
> correctly after this RFC.
>
> Nikita
>
> Thanks for the analysis,
>
> Given the confirmation that the impact is minimal (rather beneficial), I'll 
> add this to the RFC and start voting tomorrow.
>
> Bob

Maybe we should have a longer timeframe and deprecate in 8.0 and
change precedence in 9.0, similar to how it might be done with ?:
changing to non-assoc in 8.0 and maybe right-assoc in 9.0 or 10.0?

Should we have a secondary vote for that?

Regards, Niklas

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

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Niklas Keller]

> Hey,
>
> I feel like concatenation having the same precedence than addition and 
> subtraction is promoting programmers to make mistakes. Albeit typically easy 
> to catch ones, it is a quality of life change at least.
>
> Hence I'm proposing a RFC changing the precedences:
> https://wiki.php.net/rfc/concatenation_precedence
>
> Bob

Hey Bob,

if we decide to do this, there should definitely be a deprecation
notice in 7.4, I wouldn't even add a vote option for this, but make it
part of the primary vote.

An alternative to prevent mistakes in this regard is making this a
compile error and requiring parenthesis.

Regards,
Niklas

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

Re: [PHP-DEV] [RFC] Abolish Short Votes

[Niklas Keller]

Resend, because sent from the wrong address previously.

+1, but it should probably be possible to extend the voting period once
started, but not shorten it. This allows for extension during holidays in
case the author didn't think about that when starting the vote.

Regards, Niklas

Joe Watkins  schrieb am Do., 21. März 2019, 19:20:

> Evening internals,
>
> I'd like to raise for discussion another minor, self contained change to
> the voting RFC:
>
> https://wiki.php.net/rfc/abolish-short-votes
>
> This seems like another no-brainer to improve and clarify the voting
> process. As with abolishing narrow margins, I'm focused on this one detail
> and wider discussion of how we may improve other parts of the voting RFC is
> not appropriate in this thread: We either have a consensus that this detail
> should be changed or we don't, we do not need to discuss any other details
> here.
>
> Cheers
> Joe
>

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Niklas Keller]

Am Mo., 4. März 2019 um 18:00 Uhr schrieb Nikita Popov :
>
> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski  wrote:
>
> >
> >
> > On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov  wrote:
> >
> >> Hi internals,
> >>
> >> I think it is well known that == in PHP is a pretty big footgun. It
> >> doesn't
> >> have to be. I think that type juggling comparisons in a language like PHP
> >> have some merit, it's just that the particular semantics of == in PHP make
> >> it so dangerous. The biggest WTF factor is probably that 0 == "foobar"
> >> returns true.
> >>
> >> I'd like to bring forward an RFC for PHP 8 to change the semantics of ==
> >> and other non-strict comparisons, when used between a number and a string:
> >>
> >> https://wiki.php.net/rfc/string_to_number_comparison
> >>
> >> The tl;dr is that if you compare a number and a numeric string, they'll be
> >> compared as numbers. Otherwise, the number is converted into a string and
> >> they'll be compared as strings.
> >>
> >> This is a very significant change -- not so much because the actual BC
> >> breakage is expected to be particularly large, but because it is a silent
> >> change in core language semantics, which makes it hard to determine
> >> whether
> >> or not code is affected by the change. There are things we can do about
> >> this, for example the RFC suggests that we might want to have a transition
> >> mode where we perform the comparison using both the old and the new
> >> semantics and warn if the result differs.
> >>
> >> I think we should give serious consideration to making such a change. I'd
> >> be interested to hear whether other people think this is worthwhile, and
> >> how we could go about doing it, while minimizing breakage.
> >>
> >
> > I generally like the direction and think we should seriously consider it.
> >
> > I think that before we make any decisions on this, or even dive too deep
> > into the discussion - we actually need to implement this behavior,
> > including the proposed INI setting you mentioned we might add in 7.4 - and
> > see what happens in some real world apps, at least in terms of potential
> > danger (as you say, figuring out whether there's actual breakage would
> > require a full audit of every potentially problematic sample.  Ultimately,
> > I think there's no question that if we were to start from scratch, we'd be
> > going for something along these lines.  But since we're not starting from
> > scratch - scoping the level of breakage is key here.
> >
> > Zeev
> >
>
> Totally agree that assessing the amount of breakage in real code is key
> here. I have now implemented a warning for PHP 7.4 (for now unconditional,
> no ini setting) that is thrown whenever the result of a comparison is going
> to change under the currently proposed rules:
> https://github.com/php/php-src/pull/3917
>
> I've done a few initial tests by running this against the Laravel, Symfony
> and pear-core. The warning was thrown 2 times for Laravel, 1 times for
> Symfony and 2 times for pear-core. (See PR for the results.)
>
> Both of the warnings in pear-core pointed to implementation bugs. The
> Symfony warning was due to trailing whitespace not being allowed in numeric
> strings (something we should definitely change). One of the Laravel
> warnings is ultimately a false-positive (does not change behavior), though
> code could be improved to avoid it. I wasn't able to tell whether the other
> one is problematic, as it affects sorting order.
>
> I have to say that this is a lot less warnings than I expected. Makes me
> wonder if I didn't make an implementation mistake ^^
>
> Regards,
> Nikita

Most warnings will not come from framework code, but code interfacing
with browsers, I guess.

Regards, Niklas

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

Re: [PHP-DEV] wiki.php.net

[Niklas Keller]

Hey all,

the upgrade to the latest release is live now. Please report any
issues directly to me.

Regards, Niklas

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

Re: [PHP-DEV] wiki.php.net

[Niklas Keller]

I am. I already wanted to make the upgrade last weekend, but didn't
find the time. Hopefully I'll find the time for that tomorrow.

Regards, Niklas

Am Do., 14. Feb. 2019 um 09:33 Uhr schrieb Sebastian Bergmann
:
>
> Who is in charge of wiki.php.net and updates for its software? I ask
> because every time I am (logged in) on that site I see warnings such as
>
> Hotfix release available: 2018-04-22b "Greebo". upgrade now!
> Hotfix release available: 2018-04-22a "Greebo". upgrade now!
> New release available: 2018-04-22 "Greebo". upgrade now!
> Hotfix release available: 2017-02-19f "Frusterick Manners". upgrade now!
>
> I don't know if any of these updates are critical but maybe the software
> should be updated anyway?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] RFC Abolish Narrow Margins

[Niklas Keller]

> I'll reiterate my main two issues with this RFC:
> - I do think that we need 50%+1 votes for certain decisions.  Naming the
> next version of PHP, or even deciding to release it outside of the yearly
> cycle should not require a 2/3 vote.  It's not so much erring on the side
> of being conservative - it's enforcing a bias for status-quo that simply
> doesn't exist in these issues.  Is it the end of the world that we won't
> have it?  No, but it's better that we would.
> - More importantly, the voting base issue must be solved before we change
> the voting rules.  I find it extremely problematic process-wise that we'll
> change the rules using a voting base that was never defined to be valid in
> the first place.

It's the only definition we currently have. We have to rely on the
same voting base to change the voting base. I don't see how voting on
all other RFCs is fine, but voting on this one isn't.

> You mentioned that you don't see why the two issues are
> interlinked - and you may be right, it's more that one is dependent on the
> other.  Voting eligibility is the first question we should answer, and it
> should only be followed by the voting rules themselves.

We currently have an answer to voting eligibility. It's one you may
not like, but changing that is completely independent of changing
voting margins.

Regards, Niklas

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

Re: [PHP-DEV] [RFC] JIT

[Niklas Keller]

> > Can you give some information on if there are pre-conditions that
> > must hold for a function to be jitted, or quit conditions that force
> > the JIT to be reverted for a function?
>
> -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
> tag. It's possible to extend this manual control.

Shouldn't we introduce annotations instead of relying on doc comments?

Regards, Niklas

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

Re: [PHP-DEV] RFCs "under discussion"

[Niklas Keller]

Am Di., 5. Feb. 2019 um 18:40 Uhr schrieb Stanislav Malyshev
:
>
> Hi!
>
> Looking at our RFC page, we have over 50 RFCs under discussion. This is
> obviously not true - and can not be true, really, it's impossible to
> properly discuss 50+ RFCs at a time, and indeed most of these aren't
> being currently discussed. I propose to clean up that section and move
> RFCs for which there is no active discussion for, say, the last month,
> to separate status. "In Draft" status seem to suggest RFCs that have not
> yet been announced, so we need some other status for RFCs that have been
> announced but not being actively discussed. "Work in Progress" maybe?

I think it's fine moving them back to "In Draft".

Regards, Niklas

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

Re: [PHP-DEV] [RFC] [VOTE] FFI - Foreign Function Interface

[Niklas Keller]

Am Sa., 22. Dez. 2018 um 11:32 Uhr schrieb Nikita Popov :
>
> On Thu, Dec 20, 2018 at 4:13 PM Dmitry Stogov  wrote:
>
> > Hi internals,
> >
> >
> > The FFI RFC is turned into voting state.
> >
> >
> > https://wiki.php.net/rfc/ffi
> >
> >
> > There were very few minor changes since the initial proposal, e.g.
> > renaming FFI:array_type() into FFI::arrayType()
> >
> >
> > Thanks. Dmitry.
> >
>
> My main concern here is that this is a very new extension and I think that
> apart from you barely anyone had a chance to actually implement something
> based on it and gain experience using the proposed API. Bundling an
> extension with PHP means that the API becomes frozen in time and it becomes
> very hard to change anything.

Same here, I think it's better to have it as an extension for now, so
people have time to experiment with it.

In case the vote passes, do we want to mark the feature explicitly as
experimental and not covered by the usual BC guarantee?

Regards, Niklas

> I think that having FFI support is important, but I'm afraid that once we
> bundle this extension and it will see more usage, it will quickly turn out
> that the API needs to change to make it easier to use or accommodate more
> use-cases.
>
> My other concern is platform support. FFI is by nature a rather platform
> dependent. The RFC says that the extension is currently tested on Linux and
> Windows. It would be great if someone using such a system can confirm
> whether it also works on OSX and FreeBSD, so we at least have coverage of
> the major platforms.
>
> Nikita

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

Re: [PHP-DEV] [RFC] [VOTE] Improve openssl_random_pseudo_bytes()

[Niklas Keller]

Hey Sammy,

could you please turn your patch into a PR, so it's easier to comment?

Thanks,
Niklas
Am Fr., 2. Nov. 2018 um 20:30 Uhr schrieb Sammy Kaye Powers :
>
> Hey internals!
>
> Given there has been at least two weeks of discussion around the RFC,
> "Improve openssl_random_pseudo_bytes()" and there doesn't seem to be
> any outstanding issues, I have moved the RFC into voting phase.
>
> The voting period lasts two weeks; from now until 2018-11-16.
>
> The RFC can be found here:
> https://wiki.php.net/rfc/improve-openssl-random-pseudo-bytes
>
> Happy voting! :)
>
> Thanks,
> Sammy Kaye Powers
> sammyk.me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Re: RFC Proposal

[Niklas Keller]

I'd be fine with throwing exceptions in PHP 7.4, but maybe a warning
in PHP 7.4 and an exception in 8.0 then?

Things like that can be a pretty stupid error that doesn't get
noticed, and there are probably not many use cases checking the return
to be false and then not throwing an exception.

Regards, Niklas
Am Sa., 11. Aug. 2018 um 14:30 Uhr schrieb Christoph M. Becker
:
>
> On 10.08.2018 at 22:15, Jesse G. Donat wrote:
>
> > I'm measuring reaction for an RFC
> >
> > Essentially right now preg regex's fail silently - and you have to
> > actually check them manually with preg_last_error - something I've
> > never actually seen done in code.
> >
> > see:
> >
> > https://github.com/php/php-src/pull/2910
> > https://bugs.php.net/bug.php?id=70110
> > https://bugs.exim.org/show_bug.cgi?id=1663
> >
> > I'd like to propose that, in line with the recent JSON changes, the
> > preg methods be made to throw exceptions (or at the very least -
> > warnings) rather than fail silently as I believe this is a bad
> > behaviour.
> >
> > I personally do not have the low level coding knowledge needed to do
> > this, nor do I personally know anyone who does, so I would be
> > submitting this as a "concept"
> >
> >
> > Thank you ahead of time!
> >
> > This will be my first RFC submission, so I hope I'm doing this right.
>
> Thanks for bringing this up.  In principle, I'd like better feedback for
> failing PCRE functions, but I'm rather concerned regarding the BC break.
>  For json_(en|de)code() it was simple to just add another option flag,
> but some of the PCRE functions (e.g. preg_replace()) do not have an
> $options/$flags parameter yet, but already too many (optional)
> parameters.  Perhaps it would be best to postpone this to PHP 8, where
> additional warnings, and maybe even exceptions, would be acceptable.
>
> Anyhow, the implementation might be as simple as
> .
>
> --
> Christoph M. Becker
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Re: PHP 7.1.21

[Niklas Keller]

Please announce the re-tag in a separate thread. Everyone that pulled
while the tag existed will have to delete it manually locally.

Regards, Niklas
Am Do., 2. Aug. 2018 um 07:24 Uhr schrieb Anatol Belski :
>
> Hi,
>
> > -Original Message-
> > From: Peter Kokot 
> > Sent: Thursday, August 2, 2018 6:56 AM
> > To: php...@ehrhardt.nl
> > Cc: Internals 
> > Subject: Re: [PHP-DEV] Re: PHP 7.1.21
> >
> > It seems to be resolved now and versions and tags done properly.
> >
> > Should in this case there be also a merge done from PHP-7.1 to all later
> > branches?
> >
> Nope, it is only relevant for the release branch. But the wrong tag should be 
> deleted, actually.
>
> Btw. please check also
>
> http://git.php.net/?p=php-src.git;a=blob;f=README.MAILINGLIST_RULES;h=8fafbd717dfac6564a144f1b361be655a14694fb;hb=HEAD#l67
>
> Regards
>
> Anatol

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

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

[Niklas Keller]

Am So., 22. Juli 2018 um 18:52 Uhr schrieb Christoph M. Becker
:
>
> On 22.07.2018 at 18:40, Niklas Keller wrote:
>
> > Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães 
> > :
> >>
> >> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller  wrote:
> >>
> >>> It'd be great to use an OO approach instead of "magic" array keys,
> >>> e.g. like this:
> >>>
> >>> https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php
> >>
> >> While I do agree with the sentiment:
> >> - That would have been an even greater departure from the original RFC.
> >> - This is currently a purely procedural API. If this were about an
> >> hypothetical `ResponseHeaders::setCookie` it would definitely be the way to
> >> go.
> >
> > why does it have to be an all or nothing approach? It's perfectly fine
> > to have a function that accepts an object.
>
> We have an already accepted (29:3) RFC[1], which just lacks
> implementation.  Departing from the solution, which we agreed upon, in
> some details (such as suggested by Pedro) might be okay, but using
> objects instead of arrays is certainly not.

We can always have a second RFC that changes a previous RFC. It'll
land in PHP 7.4 then, but that's not an issue for me.

Regards, Niklas

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

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

[Niklas Keller]

Am So., 22. Juli 2018 um 18:11 Uhr schrieb Pedro Magalhães :
>
> On Sun, Jul 22, 2018 at 2:47 PM Niklas Keller  wrote:
>
> > It'd be great to use an OO approach instead of "magic" array keys,
> > e.g. like this:
> >
> > https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php
> >
> > Regards, Niklas
> >
>
> Hi,
>
> While I do agree with the sentiment:
> - That would have been an even greater departure from the original RFC.
> - This is currently a purely procedural API. If this were about an
> hypothetical `ResponseHeaders::setCookie` it would definitely be the way to
> go.
>
> Regards,
> Pedro

Hey Pedro,

why does it have to be an all or nothing approach? It's perfectly fine
to have a function that accepts an object.

Regards, Niklas


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

Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

[Niklas Keller]

Am So., 22. Juli 2018 um 14:16 Uhr schrieb Andrey Andreev :
>
> Hi,
>
> On Sun, Jul 22, 2018 at 2:21 AM, Pedro Magalhães  wrote:
> > On Sat, Jul 21, 2018 at 11:26 PM Andrey Andreev  wrote:
> >>
> >> Yes.
> >>
> >> All other "options" are actual *cookie attribute* names, as defined by
> >> the various IETF RFCs, while "lifetime" is just a convenient name used
> >> by PHP. It doesn't correspond to a particular attribute, but instead
> >> the values for the Expires and Max-Age attributes are derived from it.
> >> I believe during discussion I insisted that the parameter be called
> >> "attributes", for this very reason.
> >
> >
> > Hi,
> >
> > While I do understand your reasoning, I find it extremely unfriendly to the
> > user of the function to ask for one parameter separate from all the others
> > for that reason alone.
> > Also, keep in mind that all this function does is set the `session.cookie_*`
> > ini entries. So all parameters are treated equally.
> >
>
> Ok, I can see how it can be inconvenient for
> session_set_cookie_params(), though calling it "extremely" unfriendly
> is some exaggeration IMO. But while I didn't quote that part of your
> message, you did also suggest to apply the same decision to other
> functions and so I am talking about all of them.
>
> I'd be ok with this for session_set_cookie_params() alone, but not for
> set[raw]cookie().
>
> >>
> >> On another note, I also wanted that pretty much any key/value pair to
> >> be accepted instead of raising an error, for forward compatibility.
> >
> >
> > I really believe that the user spotting errors like `['expries' => time() +
> > 3600]` faster is more valuable than FC.
> >
>
> Honestly, the fact that you chose "expires" for this particular
> example IMO only makes a stronger case for why it needs to be
> separated. :)

It'd be great to use an OO approach instead of "magic" array keys,
e.g. like this:
https://github.com/amphp/http/blob/9c0ba2f2ebfae482b3ad7a0475eb3d1f74d87949/src/Cookie/CookieAttributes.php

Regards, Niklas

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

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] Re: [RFC] Typed Properties

[Niklas Keller]

Zeev Suraski  schrieb am Di., 17. Juli 2018, 00:10:

> > Based on the feedback we received, we have decided to target PHP 7.4 for
> this
> > RFC. A main factor for this decision was that the RFC requires some
> non-trivial
> > changes to 3rd-party extensions for full compatibility. This would put
> the
> > ongoing (but nearly complete) effort to port extensions to PHP 7.3 back
> to
> > square one.
>
> As I mentioned beforehand, I think it's good it wasn't rushed into 7.3 and
> at the same time sorry it's not being targeted for 8.0.
>
> > Now that the target version is decided and the last open questions in
> the RFC
> > have been resolved, we plan to open voting tomorrow.
>
> IMHO one of the key reasons for not putting it into 7.3 was the fact that
> very little discussion about the actual proposal actually happened because
> it arrived so late in the 7.3 release cycle.  Most of the discussion under
> the Typed Properties thread actually had to do with whether or not it
> should go into 7.3, 7.4 or 8.0 - and not about the specifics of the
> proposal.  I skimmed through the thread and found just a handful of
> responses that dealt with the specific of the proposals - most of them
> unanswered (unless I'm missing some internals email somehow).
>
> With this in mind, I think that now that the meta parts are finalized, we
> should allow a bit more time for real meaningful discussion about the
> proposal to happen.  I understand that you don't want to delay this to a
> later time in the 7.4 process, but delaying it by a week or so will allow
> people to actually review the proposal in more detail without the
> uncertainty that surrounded it beforehand - and perhaps have their concerns
> addressed.  Given that 7.4's finalization date is a year away, and there
> are no conflicting RFCs in the queue - a week will not have any sort of
> negative influence on the proposal, but might have some positive impact on
> its contents.
>
> Zeev
>

I'd also like to ask for a further discussion period. Seems like there is
quite some discussion going on right now.

Regards, Niklas

>

Re: [PHP-DEV] Re:[PHP-DEV] [VOTE] array_key_first(), array_key_last(), array_value_first(),array_value_last()

[Niklas Keller]

Hey,

any reason for not having both, resulting in a total of 6 functions?

Regards, Niklas

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

Re: [PHP-DEV] Re: [VOTE] Deprecate and remove case-insensitive constants

[Niklas Keller]

> Hi Nikita,
>
> I'm a terrible person for only bringing this up now (I apologise for not
> following the list as closely as I used to), but one reason
> case-insensitive constants are maybe useful is they leave open the
> possibility of being able to access functions as values in future: like
> some constants, function names are case-insensitive, and a fallback
> could be added to constant accesses to return a closure of the function
> with the same name if no constant is found.
>
> Of course, removing case-insensitive constants wouldn't preclude such a
> feature, just make it a little more annoying to implement, so this is
> not really a significant reason to vote against. To that end, I'll vote
> in favour of this deprecation.

No, thanks. The fallback is already a bad thing for functions, we
don't need another one.

If such a feature would be implemented, it'd probably be via combined
symbol tables, making either everything case-insensitive or everything
case-sensitive.

Regards, Niklas

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

Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.3

[Niklas Keller]

I put that item onto the list.

The author of https://github.com/mikey179/bovigo-assert originally had
the issue that a function named `assert` behaves really weird.
`assert()` in namespaced code might refer to the namespaced `assert()`
function, but might also fall back to the global `assert()`. Whether
the function is jumped around or not depends on `zend.assertions`,
which is highly surprising, because it also jumps around `assert()` in
namespaced code even if an `assert()` function exists in that
namespace. Requiring an explicit `use function` is really weird.

See https://3v4l.org/8EKdA for an example. The behavior in PHP 7.0+ is
by-design and mentioned in the original assertions RFC.

Regards, Niklas
Am Mo., 9. Juli 2018 um 17:18 Uhr schrieb Levi Morrison :
>
> On Mon, Jul 9, 2018 at 8:43 AM Sara Golemon  wrote:
> >
> > On Mon, Jul 9, 2018 at 5:57 AM, Marco Pivetta  wrote:
> > > Something unclear to me here: is the removal of `assert()` affecting also
> > > my own`my\assert()` (imported via `use function`)?
> > >
> > Yes, but in fairness, your namespaced assert function is already a bit
> > broken if you're not expecting it to be elided in production
> > environments.
> >
> > -Sara
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> Can you prove this somehow? Based on how `use function my\assert;`
> works a call to `assert()` later in that file should appear to engine
> as `my\assert`, not `assert`.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Re: [PHP-DEV] [RFC] [VOTE] Class Friendship

[Niklas Keller]

Hey,

could you please fix the creation date in the RFC? It lists
2018-06-27, which would mean that the minimum discussion period
wouldn't be over, yet, but it's actually been created somewhen last
year.

Regards, Niklas

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

Re: [PHP-DEV] PHP 2^3

[Niklas Keller]

Hey Dmitry,

>
> hi Aaron,
>
>
> On Jun 25, 2018 10:49 PM, Aaron Piotrowski  wrote:
>
> > On Jun 25, 2018, at 7:30 AM, Zeev Suraski  wrote:
> >
> >
> > 2. Better support long-running, async-based, microservices-focused 
> > execution model.  It's probably no secret that one of the key reasons Node 
> > is gaining popularity is because it can handle a huge number of concurrent 
> > connections issuing relatively lightweight requests very efficiently - 
> > which is a good match for modern microservices based architectures.  There 
> > are already several projects available for PHP that aim to provide similar 
> > functionality - most notably ReactPHP and more recently Swoole.
> > The main thing that is missing is that most of PHP's IO doesn't support 
> > async execution.  What I think we should do is add as much support for 
> > async IO as possible across the various extensions and streams - so that 
> > using something like Swoole would become practical for more use cases.  
> > More specifically - the goal would be to provide extension authors with 
> > mechanisms that they can use to make their extensions/functions optionally 
> > asynchronous, without having to tackle the job entirely on their own.  
> > While we've done some research into this area, it requires a lot more 
> > research - but I'm cautiously optimistic that it can be done.  We would 
> > potentially want to use libuv for this task, and potentially rewrite or 
> > otherwise refactor parts of the PHP streams system.
> >
>
> Regarding async, are you referring to the Fiber extension? In my opinion, 
> fibers would be the best approach for async in PHP. After using async/await 
> in other languages, it doesn't offer a significant gain over what's already 
> possible in PHP with generator-based coroutines in Amp. Using the fiber 
> extension and a green-thread library that resumes fibers based on promise 
> resolution [1], we've been able to write async code without the need for 
> yield or await [2], with async functions having proper return types (i.e. not 
> promise, but the type the promise would resolve to). Joel Wurtz has also put 
> together a PoC of using Doctrine asynchronously using the fiber extension and 
> Amp [3].
>
> Febers/couroutines is one of the goals.
> Another possible goal — event-loop primitives for internal extensions (e.g. 
> async DB queries)
> I think, we don't need async/await keywords or promises implementation in core
> Anyway, as an expert in async PHP, you should tell us, what you really need 
> from the PHP core...
> I would be glad to hear your oppinion.
>
> Thanks. Dmitry.

Fibers are the major feature we're looking forward to, because it
allows async I/O in places that do not account for async, e.g. also
re-using interfaces designed for sync applications. Apart from that,
we want to avoid the boilerplate we currently have to write, i.e.
Amp\call wrapping a generator function.

We think that a methodless "Promise" / "Awaitable" type + fibers
implemented with keywords are the preferred way over the current Fiber
draft in the long run.

Fibers allow for transparent async I/O, which means we could maybe
transparently upgrade file_get_contents and others to use async I/O in
future versions, but something like that obviously needs an event-loop
in core.

That said, it's definitely something we want to push to PHP 8, but
nothing that has to be discussed in too much detail in this thread.

Regards, Niklas

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

Re: [PHP-DEV] [VOTE] Fiber API

[Niklas Keller]

Hey Haitao,

there doesn't seem to be any voting snipped on that page, so there's
no actual vote yet.
Also, the open issues section should usually be empty when the vote starts.

The implementation in its current state is very limited and not really
useful to real-world applications.
Written code can't even be tested with common testing tools such as
PHPUnit, because PHPUnit relies on reflection, which is unsupported by
the current RFC.

Additionally, the "why not as extension" doesn't really have a good
reasoning. In its current state, I think it's better suited as an
external extension.

I'd really like to get fibers into PHP, but not in that state, sorry.

Regards, Niklas

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

Re: [PHP-DEV] Re: desiring a PHP.net wiki account

[Niklas Keller]

This issue has been resolved, thanks for your patience. :-)

Regards, Niklas

Am Do., 7. Juni 2018 um 15:23 Uhr schrieb Christoph M. Becker <
cmbecke...@gmx.de>:

> On 07.06.2018 at 14:28, Simon Hamp wrote:
>
> > My name is Simon Hamp (wiki username: simonhamp). I'd like to join the
> RFC wiki to stay up to date on proposed PHP developments. I'm open to
> assisting with anything you need help on.
> >
> > I haven't been able to register because of the following errors:
> >
> > There was an unexpected problem communicating with SMTP: Could not open
> SMTP Port.
> > Looks like there was an error on sending the password mail. Please
> contact the admin!
> >
> > Please let me know when I can attempt to sign up again.
>
> See .  Hope that this issue will
> be resolved soon. :)
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Parse error: Invalid body indentation level

[Niklas Keller]

Am Di., 29. Mai 2018 um 07:34 Uhr schrieb Sebastian Bergmann <
sebast...@php.net>:

> Am 28.05.2018 um 22:16 schrieb Nikita Popov:
> > Good point, I have added a note in UPGRADING in
> >
> https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c
>
> Thank you so much, Nikita!
>

Can't we ignore any delimiter occurrence that's indented more than the
previous lines to keep the BC break lower?

Regards, Niklas

[PHP-DEV] [RFC] Deprecation of uniqid()

[Niklas Keller]

Hey,

I hereby propose to deprecate uniqid(). There have been attempts to fix it (
https://wiki.php.net/rfc/uniqid), but those were rejected during
discussion, because there's no possible fix without breaking BC. Instead of
a subtle BC break, this RFC favors the deprecation and moving users to
other functions.

It's to be discussed whether the function should be removed with PHP 8.0 or
just deprecated to avoid fully breaking things where it's not strictly
necessary. A deprecation will probably avoid most new usages, which is the
main goal.

RFC: https://wiki.php.net/rfc/deprecate-uniqid

Kind Regards,
Niklas

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

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Niklas Keller]

Hey,

> Problem with checking array on assignment is that it could be N dimensions
> deep and one would have perform check for each item in each dimension for
> mutable values which could have some performance implications.

if you want to enforce that in userland now, you have even higher
performance implications. I wouldn't worry about the performance of
edge cases and take away a feature for everybody else because of that.

If there's a better internal implementation, it can always be improved later.

> Regarding constructor call, upon first initialization of object, you are
> allowed to assign values to properties, after constructor is executed,
> object is locked. If you try to call again constructor on the same object it
> would fail as soon as execution reaches first assignment statement because
> object was already marked as locked.

Sounds good! So it's already implemented basically.

> I agree that it would be better to pass by value but I am not sure how would
> that impact the way we currently manage objects in object store.

If we both agree it would be the better way, why not draft an RFC for
it and find someone who knows how to implement it?

Regards, Niklas

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

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Niklas Keller]

Hey,

> I do have rough idea how to go about arrays possibly without recursive
> scan, I have to try couple of things, it could work if some checks are
> moved to zval level. For now it is in the future scope unless I manage to
> handle the within week or two.

What's the issue with a one-time runtime check on assignment?

> First two proposals are valid points. Regarding disabling constructor, that
> would fail as soon as you try to write properties in constructor since
> object is already "locked".

You lock the object after the constructor has been called, not
afterwards. If you don't do that, your objects won't be immutable.

I like the RFC, but generally I think value objects that are passed
by-value instead of by-reference are the better way to solve the
problem.

Regards, Niklas

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

Re: [PHP-DEV][RFC][DISCUSSION] Immutability

[Niklas Keller]

Hey,

> If you do allow arrays, they would have to follow the same rules as the 
> immutable object.
>
> Alternatively, perhaps an ImmutableArrayObject would be a good addition or 
> followup to the RFC.

That would just move the problem and doesn't have any benefit over
directly allowing arrays, right?

> Some further points to harden the implementation:
>
> - I see that resources and references are disallowed (which is good). If you 
> have not already done so, you may wish to disallow streams as well.

Streams are resources, am I missing something?

Regards, Niklas

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

Re: [PHP-DEV] Re: [RFC] [Discussion] Arrays starting with a negative index

[Niklas Keller]

Hey,

"Will no longer produce any output." in the BC example is wrong, it
will produce a notice due to an undefined index then.

> NOTE: If accepted, during the deprecation phase the following E_DEPRECATED 
> notice would be emitted in cases where the behavior will change:

I guess that means also $a[-3] = true; $a[] = false; will emit a
deprecation notice?

Regards, Niklas

2018-02-22 18:38 GMT+01:00 Pedro Magalhães :
> On Tue, Feb 13, 2018 at 8:03 PM, Pedro Magalhães  wrote:
>
>> Hi internals,
>>
>> I want to bring up this RFC once again given that now seems to be the
>> right timing for it. I have previously canceled the vote when I initially
>> proposed this to land on 7.2 which was seen as too big of a BC for a minor
>> version. On a second attempt targeting 8.0 I have also canceled the vote as
>> the inclusion of a deprecation notice in cases where the behavior will
>> change warranted further discussion.
>>
>> To address these issues, the current version of the RFC will have 2
>> separate votes:
>> - Introduce the new behavior on 8.0
>> - Introduce a deprecation notice on 7.3
>>
>> For those not familiar with the RFC, the general idea is that currently,
>> any array that has a number n as it's first numeric key will have for it's
>> next implicit key either n+1 if n >= 0 or 0 if n < 0. This RFC proposes to
>> make this consistent by always using n+1 regardless of the sign of n.
>> In code:
>> $a[-2] = true; // Current: Key is -2, RFC: Key is -2
>> $a[] = true; // Current: Key is 0, RFC: Key is -1
>> $a[] = true; // Current: Key is 1, RFC: Key is 0
>>
>> I invite you to read the full RFC: https://wiki.php.net/rfc/
>> negative_array_index and bring up any issues you see with the current
>> version before the voting period starts.
>>
>> Looking forward for any feedback.
>>
>> Regards,
>> Pedro Magalhães
>>
>
> Hi internals,
>
> I'd like to open the voting for this RFC in 5 days (27/2).
> Please bring up any feedback you may have about it before the voting period
> starts.
>
> Thanks in advance,
> Pedro Magalhães

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

Re: [PHP-DEV] About assert()

[Niklas Keller]

> In PHP 7 only foo() will be in the backtrace.  In PHP 5 assert will be
> listed as well.
>
> What you are proposing has already been done.  It's also why
> zend.assertions has three settings: 1: on, -1: off, 0: emulate PHP 5.
> Unless you have code on your hands that is breaking when the -1 setting is
> used, the 0 setting should never be used.

I don't think that's true. 0 can be used to dynamically switch
assertions on and off, which can be useful in some applications.

Regards, Niklas

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

Re: [PHP-DEV] [RFC] Fiber support (again)

[Niklas Keller]

>> There would also need to be something that stops the script execution
>> as soon as there's no non-suspended Fiber anymore.
>
> As you pointed out, the main process cannot be a Fiber because it need to
> schedule other fibers.

The conclusion is wrong. There just needs to be a way to access this
fiber, e.g. Fiber::getMain().

>>
>> Regarding the internal calls: A core dump / segfault in case of
>> Fiber::yield() inside an internal function is unacceptable. It doesn't
>> give the user any clue what's wrong. Instead, an exception could be
>> thrown from Fiber::yield(), which just bubbles up then. Full support
>> for internal functions could be added at a later point then.
>
> It is impossible to solve this issue before we get a pure stackless Zend VM.
>
> If this feature can be merged into PHP 7.3, we could introduce a new counter
> to record the zend vm nested level. Every time you enter an internal call,
> let zend increment the counter, and decrement it when out.
>
> When we create a fiber, we remember current vm nested level. When zend execute
> Fiber::yield,it will throw an error if the current vm nested level is not
> equal to the original one.
>
> This feature cannot be implemented without changing the zend vm code base.

You're proposing this as language feature, not as an external
extension, so that is entirely fine and actually the reason why this
should be in core instead of an external extension.

Regards, Niklas

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

Re: [PHP-DEV] [RFC] Fiber support (again)

[Niklas Keller]

> Hi, all,
>
> I have updated the RFC https://wiki.php.net/rfc/fiber
>
> changes list:
>
> - introduce the `throw(Exception $exceptin)` API
> - record issues discussed

What about my suggestion of making PHP's main() automatically a Fiber,
which avoids Fiber::yield() being used outside of a Fiber, because
everything is a Fiber?

This would require another continuation mechanism, as nothing has
access to the automatically created main()-Fiber otherwise.

There would also need to be something that stops the script execution
as soon as there's no non-suspended Fiber anymore.

Regarding the internal calls: A core dump / segfault in case of
Fiber::yield() inside an internal function is unacceptable. It doesn't
give the user any clue what's wrong. Instead, an exception could be
thrown from Fiber::yield(), which just bubbles up then. Full support
for internal functions could be added at a later point then.

Regards, Niklas


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

Re: [PHP-DEV] [RFC] Fiber support (again)

[Niklas Keller]

2018-02-09 21:53 GMT+01:00 Björn Larsson :
> Regarding these potential new keywords await & async.
> Any need to look into how Hacklang uses these keywords?
> Could there be portability aspects on the functionality in
> itself?

No, there's no need to look at Hacklang and be compatible. They do
their own thing.

Regards, Niklas

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

Re: [PHP-DEV] [RFC] Fiber support (again)

[Niklas Keller]

>
> > The language should offer a sane API, not the absolute minimum required
> to
> > work for these things.
>
> The Ruby's Fiber do offer a live? method but does not have a getStatus
> method.
> The Lua's coroutine only offer a status method.
>
> So do we really need to offer three additional helper method? Or what is
> your
> advice about these API?


What's the downside?

>
> >>> - What about throwing exceptions into a fiber?
> >>
> >> Currently does not support throw exception into the fiber. User land
> code
> >> could check
> >> the value of Fiber::yield and throw exception themselves. The Ruby's
> Fiber
> >> and Lua's
> >> coroutine also does not support such api as well.
> >
> >
> > And throw the exception where? That means async code with fibers can't
> > really handle errors?
>
> Actually you can transfer any thing to Fiber by the resume method. And you
> can
> check the return value of Fiber::yield to handle error.
>
> Fiber is designed as a primitive, low level, and lightweight feature. User
> land
> code seldom not need to use them directly in your normal code.
> So the following is not a big problem,
>
> $a = Fiber::yield(...);
> if ($a === false) {
>throw new Exception(...);
> }
>
> And both the Ruby and Lua does not offer such API as well.
>

We have started building a PoC library on top of Fibers, see
https://github.com/amphp/green-thread/blob/7bd3470e7986169372d5e9c39500f3652091b512/src/functions.php
.

We'd like to avoid the additional `await()` function and rather directly
couple Fibers with promises in the PHP core.

Using `await` (the keyword) instead of `Fiber::yield()` feels way better
and avoids the need for any wrapping libraries for what should be a core
feature.

`async` can be added to create a new Fiber and Fiber can implement Promise.


> >
> >>
> >>>
> >>> - Using Fiber::resume() to initialize the fiber and resume feels
> >> awkward. Separate methods again would be better here, perhaps
> >> Fiber::init(...$args) and Fiber::resume($send).
> >>
> >> All Fiber created with a suspended status. So make resume to do both the
> >> init and resume
> >> do make sense.
> >>
> >
> > It does't make sense to me. Reading the example in the README and
> > understanding why the first resume() takes two arguments instead of one
> > took me quite some minutes.
>
> This Ruby's Fiber and Lua's coroutine using one resume API to init and
> resume
> the coroutine. I do not think a dedicate is really required.
>
> The generator cannot be init by it's send method. And if you want to
> implement
> coroutine feature(without stack) by it, you have to write code
>
> function run() {
> if ($this->beforeFirstYield) {
> $this->beforeFirstYield = false;
> return $this->coroutine->current();
> } else {
> $retval = $this->coroutine->send($this->sendValue);
> $this->sendValue = null;
> return $retval;
> }
> }
>
> It is verbose.
>

That's why we directly prime coroutines on creation, see
https://github.com/amphp/amp/blob/4a742beb59615f36ed998e2dc210e36576e44c44/lib/Coroutine.php#L36-L52


> See https://nikic.github.io/2012/12/22/Cooperative-
> multitasking-using-coroutines-in-PHP.html
>
> >
> >> Please see Ruby Fiber API https://ruby-doc.org/core-2.2.0/Fiber.html.
> >>
> >>>
> >>> - What happens if the sub1() function in the RFC is invoked outside of
> a
> >> fiber?
> >>
> >> You will get a Fatal Error like
> >> Fatal error: Uncaught Error: Cannot call Fiber::yield out of Fiber
> >>
> >>> - I think a keyword here would be beneficial, even if it has a minor BC
> >> impact. Fibers could then be written like generators. `await` or `emit`
> as
> >> a keyword perhaps? This would be a less verbose API, feel less magical
> (a
> >> static method call that actually pauses execution feels out of place),
> and
> >> would allow Fibers to be returned from methods, named functions, etc
> with
> >> less boilerplate.
> >>
> >> Wishing this to be accepted by the community in the PHP 7.3, so no
> keyword
> >> is accepted.
> >> And if the community cannot accept, the Fiber can be still distributed
> as
> >> a standalone
> >> extension. So we cannot depend on a new keyword.
> >
> >
> > Right, if it's a standalone extension it can't use a new keyword, but as
> a
> > language feature it totally can.
>
> In my opinion, using a keyword or call a method is just a coding style
> problem.
> Introducing a new keyword does not offer any benefit by makes a minor BC.
>

It makes code way easier to write IMO.


> Both Ruby's Fiber and Lua's coroutine does not required a dedicate keyword.
>
> > Looking at the current README, there are two issues that must be
> completely
> > solved IMO before accepting this:
> >
> >> Each Fiber has a separate 4k stack. You can use the fiber.stack_size ini
> > option to change the default stack size. You can also use the second
> > argument of Fiber::__construct to set the stack size on fly.
> >
> > Resizing of the stack should happen automatically, just 

Re: [PHP-DEV] [RFC] Fiber support (again)

[Niklas Keller]

>
> > - How do you determine when a fiber has returned? Looking at the source,
> it appears Fiber::status() must be used, comparing against constants.
> Separate methods similar to Generator would be better IMO. e.g.:
> Fiber::alive(), Fiber::suspended(), Fiber::running()
>
> Offering methods like Fiber::alive, Fiber::running makes no difference to
> check the Fiber::status() return value. This is just a style issue. And as
> a language feature,
> Fiber only offer the essential API and let other works to the user land.


The language should offer a sane API, not the absolute minimum required to
work for these things.


> > - What about throwing exceptions into a fiber?
>
> Currently does not support throw exception into the fiber. User land code
> could check
> the value of Fiber::yield and throw exception themselves. The Ruby's Fiber
> and Lua's
> coroutine also does not support such api as well.


And throw the exception where? That means async code with fibers can't
really handle errors?


>
> >
> > - Using Fiber::resume() to initialize the fiber and resume feels
> awkward. Separate methods again would be better here, perhaps
> Fiber::init(...$args) and Fiber::resume($send).
>
> All Fiber created with a suspended status. So make resume to do both the
> init and resume
> do make sense.
>

It does't make sense to me. Reading the example in the README and
understanding why the first resume() takes two arguments instead of one
took me quite some minutes.


> Please see Ruby Fiber API https://ruby-doc.org/core-2.2.0/Fiber.html.
>
> >
> > - What happens if the sub1() function in the RFC is invoked outside of a
> fiber?
>
> You will get a Fatal Error like
> Fatal error: Uncaught Error: Cannot call Fiber::yield out of Fiber
>
> > - I think a keyword here would be beneficial, even if it has a minor BC
> impact. Fibers could then be written like generators. `await` or `emit` as
> a keyword perhaps? This would be a less verbose API, feel less magical (a
> static method call that actually pauses execution feels out of place), and
> would allow Fibers to be returned from methods, named functions, etc with
> less boilerplate.
>
> Wishing this to be accepted by the community in the PHP 7.3, so no keyword
> is accepted.
> And if the community cannot accept, the Fiber can be still distributed as
> a standalone
> extension. So we cannot depend on a new keyword.


Right, if it's a standalone extension it can't use a new keyword, but as a
language feature it totally can.

Looking at the current README, there are two issues that must be completely
solved IMO before accepting this:

> Each Fiber has a separate 4k stack. You can use the fiber.stack_size ini
option to change the default stack size. You can also use the second
argument of Fiber::__construct to set the stack size on fly.

Resizing of the stack should happen automatically, just like generators
resize automatically.

> Fiber::yield cannot be used in internal callback

This also seems problematic and will make fibers quite less useful,
especially as these yields can happen anywhere down the stack.

Regards, Niklas

Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

[Niklas Keller]

+1

Why should it emit an E_NOTICE instead of E_DEPRECATED?

The code for the shim should probably use define() for constants instead of
eval().

Regards, Niklas

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

Michael Morris <tendo...@gmail.com> schrieb am Fr., 26. Jan. 2018, 02:06:

> On Thu, Jan 25, 2018 at 3:04 PM, Niklas Keller <m...@kelunik.com> wrote:
>
> >
> >>
> >> $a instanceof array
> >>
> >
> > That might work, but array should only return true if it's an
> > array, not for anything that implements ArrayAccess.
> >
> >
>
> Related:
>
> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <le...@php.net> wrote:
>
> >
> >
> > I see no value to this operator being applied to non-array
> > traversables.
>
>
> If an array access object can't masquerade as an array it loses some of its
> value, but Niklas is right - it is important to distinguish such objects
> from native arrays.  One solution would be to promote "iterable" to keyword
> status.  The flexibility to take any iterable will be needed I think.
>
> $a instanceof iterable
>
> Would return true for anything iterable (which we can already test with
> is_iterable() ) where all values where strings.
>
> On Thu, Jan 25, 2018 at 4:11 PM, Levi Morrison <le...@php.net> wrote:
> >
> > Our iterators cannot always be reliably rewound, such as
> > when using generators. Checking that the generator returns only
> > strings would consume all the input and would therefore be useless.
>
>
> True - I hadn't thought of those. But as of PHP 7 generators can type
> declare their return value.


They can only define generator as return type, which is what they return
when you call a generator function.

Even if you could declare the return type of the generator, you'd still
have the same problem with the yielded values.

So, given `$a instanceof iterable`, if
> $a is a reference to a generator, then the engine could check the return
> type declaration and only give true on a match without attempting to use
> the generator.
>
> We can follow this pattern farther - The return of an
> ArrayAccess::offsetGet and Iterator::current() can be similarly tested by
> instanceof rather than actually pulling data from these methods.
>
> We are having the return rely on the promise of the code, but in each case
> TypeError would be raised anyway if it breaks it's promise to instanceof so
> errors aren't being avoided.
>
>
>
> > Returns true if $a is an array (or implements array access) and that all
> >> it's members are strings.
> >>
> >> $b instanceof SomeClass
> >>
> >> Returns true if SomeClass can be iterated and contains only strings.
> >>
> >
> > This would block generics with that syntax then.
> >
>
> I don't understand this comment.
>

You restrict these type parameters to iterators, but generics are useful in
a lot more places.


> On Thu, Jan 25, 2018 at 5:28 PM, Larry Garfield <la...@garfieldtech.com>
>  wrote:
>
> >
> >
> > Is this to ensure that everything coming OUT of a collection is a given
> > type,
> > or that everything put IN a collection is a given type?
> >
>
> Ensure (or try to ensure, since reporting the promises of another method's
> return type isn't certain) that things coming OUT are a given type.  Leave
> the headache of guarding inputs for another day and RFC.
>
>
> >
> > Asserting that "at this point in time, everything in this collection is a
> > given type" is honestly fairly useless unless it's enforced to stay that
> > way.
>
>
> No more useless than type declarations are if a programmer does this...
>
> function foo (string $a) {
>   $a = (int) $a;
> }
>
> Every feature of the language can be rendered useless by the right amount
> of stupidity. No feature recommendation should be beholden to the "what if
> a moron does X?" argument.
>

Regards, Niklas

>

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

>
> On Thu, Jan 25, 2018 at 2:39 PM, Niklas Keller <m...@kelunik.com> wrote:
>
>>
>> So, given `$a collectionof string` the operator returns whether or not $a
>>> is, at that time, a collection of strings (be it an array or other
>>> iterable). It doesn't insure $a will stay that way - it's just a check of
>>> the variables status at a given moment, which is the best that can be
>>> hoped
>>> for in PHP.
>>>
>>
>> That should be a function, not an operator, unless you can bring up very
>> good arguments to make it an operator.
>>
>
> Consistency with instanceof.
>
>
>
> Hmm, it might be possible to just pile this all onto instanceof -
> following Derrick's mention of how Java does things, so here's a third
> implementation approach.  It would look like this:
>
> $a instanceof array
>

That might work, but array should only return true if it's an
array, not for anything that implements ArrayAccess.


> Returns true if $a is an array (or implements array access) and that all
> it's members are strings.
>
> $b instanceof SomeClass
>
> Returns true if SomeClass can be iterated and contains only strings.
>

This would block generics with that syntax then.


> The question is can the token parser handle that pattern?  Or does the
> current usage of < and > in their boolean form block this?
>
> If this third approach is accepted then we have no BC breaks at all since
> there's no new keyword or function. We just have a *very* expanded
> instanceof operator.
>

Regards, Niklas

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

[Niklas Keller]

Michael Morris  schrieb am Do., 25. Jan. 2018, 21:19:

> On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins 
> wrote:
>
> > On 25/01/2018 14:52, Derick Rethans wrote:
> >
> >> IMO, it makes a lot more sense to check integrity when creating the
> >> "array" structure. Instead, I would suggest to add a native Collection
> >> type, that takes a "type" as argument. They aren't quite full generics,
> >> but it does 1. fix something; 2. isn't really complicated.
> >>
> >> What I am suggesting is to add a new syntax "Collection<$type>",
> >> mimicking a class, but having a type as "argument":
> >>
> >> $a = new Collection;
> >>
> >
> > So would I be right in thinking this would mean adding basic support for
> > generics to the engine, but not letting new ones be defined in userland?
> > So, a bit like how internal or extension classes have the ability to do
> > more overloading of casts and operators than userland classes?
> >
> > If so, I like the concept, but wonder whether the parts of the
> > implementation it would need are the easy parts of the hard ones. I guess
> > not being able to inherit from the generic would get rid of a bunch of
> > complexity, but don't really know where else the challenge lies.
> >
>
> He's getting the syntax from Java.  Java collections allow you to specify
> the type they are constrained to in <> after the class name.  Type Script
> does something similar.  The problem is that Java already has the policing
> mechanics present in the runtime to police insertions into the collection
> and guarantee they are of the correct type.  PHP has no such mechanism in
> place and in previous discussion threads the primary maintainers have
> underscored that adding such is highly difficult.
>
> It is also completely tangential to and a distraction from what I propose
> and would like to focus on here.  Regardless of whether PHP ever gets a
> core class or construct for type uniform collections, the ability to verify
> that variables are a "collection of something" will remain.  That is the
> issue I want to discuss and address here - verifying that existing
> variables are a given collection type, not debating pie-in-the-sky, may
> never be implementable classes that self insure their own integrity.
>
> So, given `$a collectionof string` the operator returns whether or not $a
> is, at that time, a collection of strings (be it an array or other
> iterable). It doesn't insure $a will stay that way - it's just a check of
> the variables status at a given moment, which is the best that can be hoped
> for in PHP.
>

That should be a function, not an operator, unless you can bring up very
good arguments to make it an operator.

Regards, Niklas

>

Re: [PHP-DEV] New login to RFC

[Niklas Keller]

Hey Gabriel,

rights have been granted.

Regards, Niklas

2018-01-20 18:35 GMT+01:00 Gabriel Caruso :

> I've requested a login for _carusogabriel_ username to create a RFC for new
> function in PHP's Core.
>
>
> --
> Gabriel Caruso
>

Re: [PHP-DEV] ICU and the INTL_IDNA_VARIANT_2003 deprecation

[Niklas Keller]

2018-01-19 20:09 GMT+01:00 Andrey Andreev :

> On Fri, Jan 19, 2018 at 8:55 PM, Sara Golemon  wrote:
> > (Seriously though, who's on php 7.2, but hasn't updated ICU for that
> > long?)
>
> Probably nobody yet. The issue was uncovered in code that assumed the
> constant was available on 5.4+, as noted in the manual, but it turned
> out there's people on 5.6, 7.0 who don't have it.


Also PHP 7.1: https://github.com/zendframework/zend-validator/issues/193

We also had an issue report, but I can't find it currently, forgot to link
it from the commit:
https://github.com/amphp/uri/commit/2de94666447319d8695f2d11f3f005d5fee0876a

I think we only have to bump the minimum version once 7.4 is out, because
only 7.4 will change the default. You only get a deprecation notice now,
which is totally fine.

Regards, Niklas

Re: [PHP-DEV] php wiki user, want to contribute edits

[Niklas Keller]

>
> > Thanks, fixed!
> A few more little changes:
>
> %s/Global symbol tales/Global symbol tables/
> %s/operands jut refer/operands just refer/
>
> Thanks for the docs. I'm off to read https://wiki.php.net/phpng-upgrading
> as I got segfaults in my
> php extension when upgrading from 5 to 7 due to zend_parse_parameters()
> change from int to size_t
> on string length parameters. :)
>
> Cheers,
> Craig


Thanks, fixed.

Re: [PHP-DEV] [RFC][DISCUSSION] Strong Typing Syntax

[Niklas Keller]

Hey Michael,

I don't think the BC break is acceptable. You argue that scalar type
declarations are relatively new, but in fact they're already years old now.
They're used in most PHP 7+ packages. Even if changing types might be
discouraged, it still happens a lot.

Regards, Niklas

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Niklas Keller]

>
> Am 24.12.2017 um 15:34 schrieb Fleshgrinder:
> > I prepared a PR to add the `scalar` pseudo-type to PHP after the
> > discussions around adding a `mixed` pseudo-type. I strongly believe that
> > it makes sense to provide the most common primitive union types with
> > handy aliases even if we are going to add union types in the future to
> PHP.
>
> Thank you, Richard, for working on this.
>
> I spent a lot of time this year introducing scalar type declarations into
> existing code bases. In quite a few cases I was not able to do so because
> the existing code works with parameters that can be of two or more scalar
> types. With PHP 7.2, I can only document this outside of the code using
> @param annotations (until the code has been refactored to work with only
> one parameter type).
>
> With a "scalar" type declaration I would not have to fall back to @param
> annotations and could express the type in actual syntax.
>

If you want just two of those and not all, you'd still have to use PHPdoc
for those?

IIRC you voted against union types, which would be a better fit in that
case?

Regards, Niklas

>

Re: [PHP-DEV] spam on user notes

[Niklas Keller]

>
> hi internals,
>
> User contribution notes are flooded by spam. For example,
> http://php.net/manual/en/install.problems.bugs.php#122116
>
> The tool on master.php.net can only remove/reject the notes one by one,
> which is inefficient in this case.
> I'm wondering if there is a way can remove notes by email or ip. In
> addition, we may need to improve the user notes with anti-spam system,
> maybe Akismet?
>

I have deleted them manually now and added "earning", "bitcoin" and
"mining" to the spam list.

We at least improve the deletion process to use Ajax instead of opening a
new tab for each note.

Regards, Niklas

Re: [PHP-DEV] [RFC] Mixed Typehint

[Niklas Keller]

>
> > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
> > https://wiki.php.net/rfc/mixed-typehint
> >
> > The purpose of this RFC is to introduce "mixed" typehint on language
> level
> > to be used
> > as a valid typehint. PHP currently forces users to not use any type in
> case
> > the
> > type is mixed/unclear. This makes code inconsistent and less explicit.
> With
>
> I'm not sure what's the point of it. "mixed" means "any type". Not
> writing a type means "any type". So why waste space and add something
> that contributes nothing when everybody is already using the current
> convention and the new one does not add anything at all?


Why document code? It contributes nothing to the behavior of the code,
well, unless you parse it as annotations.

The current one isn't any convention, it's just not possible to do
something else. There's nothing that explicitly allows saying "I accept all
types", rather than "The type I accept is unspecifed".

That said, I'm not sure myself. I guess a more complex type which can't be
expressed currently (like a union type) might also use "mixed" then.

Regards, Niklas


> > mixed,
> > it should be easy to eliminate this inconsistency
>
> There's no "inconsistency" here.
>
> > and achieve fully type hinted code.
>
> This is not an "achievement" - adding prefixes for the sake of all
> variables having prefixes that mean nothing is not an "achievement". I
> do not see any point in it.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] ReflectionContext for imports and namespace

[Niklas Keller]

Andreas Hennings  schrieb am Mo., 11. Dez. 2017, 01:39:

> TLDR:
> I propose to introduce a new class \ReflectionContext (or perhaps
> \ReflectionScope?), to give information about imported aliases and the
> namespace.
>
>
> ## Background / motivation
>
> Some libraries that parse doc comment annotations, e.g. phpDocumentor,
> need to know the class aliases and the namespace that are active in
> the place (scope) where the class, function or method is declared.
>
> E.g. phpDocumentor has this class:
>
> https://github.com/phpDocumentor/TypeResolver/blob/552bf401d264a443819a66233932be6a23f59d78/src/Types/Context.php
>
> To get this information, they parse the PHP file where the class is
> defined:
>
> https://github.com/phpDocumentor/TypeResolver/blob/552bf401d264a443819a66233932be6a23f59d78/src/Types/ContextFactory.php
>
> It would be much more pleasant if PHP would provide this information
> through the reflection API.
> A custom library should not need to do an expensive and fragile
> parsing job for information that is already known.
>
> Also, this external parsing might not cover all cases, depending how
> it is implemented. E.g. local namespace scopes in curly brackets. (Who
> uses those, btw?)
>
>
> ## Proposal
>
> Make information about class aliases (imported through use statements)
> and the active namespace available through the reflection API.
>
> $reflClass = new \ReflectionClass(C::class);
> $reflContext = $reflClass->getContext();
> $aliases = $reflContext->getAliases();
>
>
> ## Details
>
> class ReflectionContext {
>
>   function getNamespace() : string {..}
>
>   /**
>* @return string[]
>*   Format: $[$alias] = $qcn
>*/
>   function getAliases() : string[] {..}
>
>   /**
>* @return string|null
>*   The qcn of the class, or null if it is a built-in type like
> "string".
>*/
>   function resolveAlias($alias) : ?string {..}
> }
>
> The $reflClass->getContext()->getNamespace() is the same as
> $reflClass->getNamespace().
>
> But having it all in the $context object allows this object to be
> passed around to components that need it.
>
>
> ## Open questions
>
> In a method doc comment, we also want to resolve the "self" keyword.
> For this, the class name is needed as well, not just external imports
> and namespace.
>
> Maybe also introduce \RefllectionMethod::getContext()? Not sure.
>
> Should it be "context" or "scope"? It is not the same. Maybe "scope"
> leads to the wrong expectations.
>

Documentation tools shouldn't run the code IMO, that means they won't have
access to that feature.

Nikic's PHP parser already contains a tool that resolves all namespaces,
you can probably write a similar visitor for the Ast that also works for
PHPdoc blocks.

Regards, Niklas

>

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Niklas Keller]

>
> This.  There's nothing undefinable about "1 instanceof \stdClass", the
> clear and obvious answer is: "No, it's not an instance of \stdClass,
> it's an integer."  The runtime result of false makes sense, the
> compile time error doesn't.  Let's relax the compile time error (fold
> it into a const false if you truly must) and call it done.  There's no
> need to be hostile to users just because the code *seems* silly.
>

This code doesn't just *seem* silly. For everything but testing whether it
works it is totally useless.

But we might turn the fatal error into a warning like we do it for "use" in
the global namespace: https://3v4l.org/ph7KW

Regards, Niklas

Re: [PHP-DEV] instanceof survives non-object variables, but crashes on non-object constants.

[Niklas Keller]

>
> That is fine for code that is broken in the first place. Similarly we added
> a warning some years back about array to string conversions.
>

Code using instanceof on possible non-objects isn't broken. instanceof
simply does an implicit is_object() check without needing an extra function
call.

I know that a change there would break Amp in quite a few places (
https://github.com/amphp/amp/search?utf8=%E2%9C%93=instanceof=) and
I'm very sure that a lot of other applications would break, too.


> The impact should be minimal as is, so persevering bc for broken usage is a
> poor argument imo
>

Why is it broken? What's wrong with the implicit is_object() check?

1 instanceof XXX *is clearly broken* on the other hand, which can be
statically verified to fail in all cases.

Regards, Niklas

Re: [PHP-DEV] C++-like function-try-block proposal

[Niklas Keller]

>
> > No, sorry. Neither Hannes nor anybody from systems@ has responded yet.
> As a workaround it should be sufficient to request a php.net account via
>  (use the same username and email address);
> after somebody has approved the account, access to the Wiki should be
> granted.
>

Sorry for the delay, a working configuration is now in place.

I hope you're able to login now after using the password reset feature.

Regards, Niklas

Re: [PHP-DEV] PHP 7.2.0 Released

[Niklas Keller]

>
> and to be clear here:
>
> a client when connecting to a server configured like below has to respect
> the cipher order of the server while
> https://www.ssllabs.com/ssltest/ exists for years to give dministrators
> of the server some help and which clients are using which cipher
>

Just minor nitpicking to get the facts right: A client does never respect
the used cipher order of the server. A client offers a number of ciphers
and the server chooses one of those, either based on its own order
(preferred) or based on the client-preferred order.

If you know other programs doing it better, research how they do it and
propose a change to PHP please.

Regards, Niklas

Re: [PHP-DEV] C++-like function-try-block proposal

[Niklas Keller]

>
> > > I did (using this e-mail address), and got the message: "The user has
> been created and the password was sent by email." However, I did not
> receive any e-mail with the password.
> >
> > Sorry for the trouble, seems like nobody tested the sign up process
> after the server migration yet. It seems like the e-mail sender
> configuration is missing.
> >
> >
> > Unfortunately, I don't know the right config, so I can't simply fix it,
> but I've sent a message to Hannes, he probably knows.
>
> Any update? The reset password feature of wiki.php.net doesn't work
> either, I receive no e-mail.
>

No, sorry. Neither Hannes nor anybody from systems@ has responded yet.

Regards, Niklas

Re: [PHP-DEV] PHP 7.2.0 Released

[Niklas Keller]

li...@rhsoft.net  schrieb am Fr., 1. Dez. 2017, 17:13:

>
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
> >> - Improve TLS constants to sane values
> >
> > This worries me a lot. Last time someone thought it was a good idea they
> > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>

We only changed the defaults in 7.2, it was possible to use the same
features before, except for the security level.

Regards, Niklas

>

[PHP-DEV] Re: Public Tags of Releases

[Niklas Keller]

>
> On Tue, Nov 28, 2017 at 10:55 AM, Niklas Keller <m...@kelunik.com> wrote:
> > it's the current practice to tag releases publicly two days before
> release
> > and then do the final QA phase. Could we please stop that?
> >
> > If there's a mistake that needs to be fixed and that's detected within
> these
> > two days, a re-tag needs to happen. If the old tag is deleted and a new
> > modified tag is published, all cloned Git repositories that already
> received
> > the old tag will keep the old tag and never receive the new tag unless
> the
> > old tag is manually removed first. That's problematic.
> >
> Agreed that tags shouldn't be moved once pushed, but is assigning a
> new version tag really that terrible?
>

No, that'd be fine, too. But IIRC there have been re-tags instead of new
tags before.


> Example: php-7.2.0 tag was just pushed by Remi for the release on
> Thursday.  If we do find a show-stopper bug, we can patch it and push
> php-7.2.0-pl1 or whatever.
>

That "or whatever" should probably be covered in the release process
document(s).


> Not a hill I need to die on either way, but I don't see the early push
> as necessarily a bad thing. Indeed, I know there are users who look
> forward to the early tag to start their builds ahead of time.  These
> parties then serve as a warning shot for that two-day cooling period.
> Could they build from branch before then? Yeah, but in at least one of
> those cases, I know that the presence of that tag is what got them
> doing it in the first place.


Correct, the tags are there, so people use them.

> If there won't be a re-tag but a new tag name instead, there's no reason
> to
> > not see the tagging as release instead of the release announcement two
> days
> > later.
> >
> Apart from the windows builds, and those pre-builders mentioned above.
>
> > If tags are necessary for the final QA phase and the QA phase should
> happen
> > before release, then these tags shouldn't be public, but in a private
> > repository instead. If tags aren't necessary, then the QA phase can use a
> > different tag or just a commit reference and the release announcement can
> > happen directly after the tagging.
> >
> Okay, that's a reasonable middle ground.  We could tag as
> php-X.Y.Z-something Tuesday, then tag again as php-X.Y.Z on Thursday.
> That would only add one step to the release process at the minor cost
> of having more tags. *shrug*
>

Why not just use the release branch instead of tags for that phase? I don't
think having a lot of these useless tags is a good thing.

Regards, Niklas

[PHP-DEV] Re: Public Tags of Releases

[Niklas Keller]

>
> Afternoon,
>
> Tags are created in release branches, these branches should not be part of
> any workflow other than our internal one.
>

I'm not talking about branches, but tags. Updating these release branches
doesn't matter and is totally fine, as these are normal branches and thus
not deemed immutable.

It's problematic to tag other than publicly, anywhere we create these tags
> is public and presumably would cause the same problem for those people who
> choose to use release branches in their workflow.
>
> Cheers
> Joe
>

Regards, Niklas

[PHP-DEV] Public Tags of Releases

[Niklas Keller]

Morning,

it's the current practice to tag releases publicly two days before release
and then do the final QA phase. Could we please stop that?

If there's a mistake that needs to be fixed and that's detected within
these two days, a re-tag needs to happen. If the old tag is deleted and a
new modified tag is published, all cloned Git repositories that already
received the old tag will keep the old tag and never receive the new tag
unless the old tag is manually removed first. That's problematic.

If there won't be a re-tag but a new tag name instead, there's no reason to
not see the tagging as release instead of the release announcement two days
later.

If tags are necessary for the final QA phase and the QA phase should happen
before release, then these tags shouldn't be public, but in a private
repository instead. If tags aren't necessary, then the QA phase can use a
different tag or just a commit reference and the release announcement can
happen directly after the tagging.

Regards, Niklas

Re: [PHP-DEV] [PHP-CVS] com php-src: ext/sodium: throw exceptions instead of errors: ext/sodium/libsodium.c

[Niklas Keller]

2017-11-28 15:27 GMT+01:00 Christian Schneider :

> Am 28.11.2017 um 14:17 schrieb Sebastian Bergmann :
> > Am 28.11.2017 um 13:56 schrieb Frank Denis:
> >> Commit:c05cbd1e775fa69ed9939796a908390f2bfb4459
> >> Author:Frank Denis  Tue, 28 Nov 2017
> 13:56:11 +0100
> >> Parents:   c219991c77e4c68f7d62963e18a1da778de0bbe0
> >> Branches:  PHP-7.2
> >>
> >> Link:   http://git.php.net/?p=php-src.git;a=commitdiff;h=
> c05cbd1e775fa69ed9939796a908390f2bfb4459
> >>
> >> Log:
> >> ext/sodium: throw exceptions instead of errors
> >
> > I am very much in favor of this change. However, making such a change in
> > PHP 7.2.1 is a BC break. Any chance to get that into PHP 7.2.0?
>
> I'm wary of turning errors into exceptions because code which was
> returning a result with libsodium before (either PECL or PHP 7.2.0) - even
> though it was generating an E_WARNING/E_ERROR - now suddenly aborts with an
> exception.
>
> Even if it was put into 7.2.0 it would break code written using the PECL
> module.
> (Side-note: I see that this case was already upgrade from E_WARNING to
> E_ERROR from PECL to PHP 7.2.0. But the program keeps running with E_ERROR
> so that's IMHO an acceptable change)
>
> This reminds me of a recent email by Linus Torvalds
> https://lkml.org/lkml/2017/11/21/356 because stopping the program due to
> something considered dangerous is debatable.
>
> Would you still consider an exception a good idea if the minimum value for
> one of the function parameters is increased in a later version of
> libsodium? Personally I'd prefer E_ERROR/E_WARNING.


I definitely want an exception there instead of an error. For a minimum
_recommendation_ a warning would be fine, but why do you prefer an E_ERROR
over an exception?

Regards, Niklas

Re: [PHP-DEV] C++-like function-try-block proposal

[Niklas Keller]

Hey Alexei,


> I did (using this e-mail address), and got the message: "The user has been
> created and the password was sent by email." However, I did not receive any
> e-mail with the password.
>

Sorry for the trouble, seems like nobody tested the sign up process after
the server migration yet. It seems like the e-mail sender configuration is
missing.

Unfortunately, I don't know the right config, so I can't simply fix it, but
I've sent a message to Hannes, he probably knows.

Regards, Niklas

Re: [PHP-DEV] net_get_interfaces()

[Niklas Keller]

Hey Sara,

I'm not sure about the naming, but I think such a function is a good idea.
Why a `net_*` prefix when it's in ext/standard? I'd suggest
`get_network_interfaces()` instead.

As previously mentioned on Twitter [1], it could be really useful for us in
amphp/socket [2].

[1] https://twitter.com/kelunik/status/934075249452306433
[2] https://github.com/amphp/socket/issues/35

Regards, Niklas

2017-11-23 23:46 GMT+01:00 Sara Golemon :

> Planning to add net_get_interfaces()
> https://github.com/php/php-src/pull/2935/files for enumerating the
> adapters on a system and their configured addresses.
> Based on a combination of my own implementation and finding out
> krakjoe and ab@ had a stalled version already.
>
> If anyone wants an RFC I'll write one up, but this is pretty small so
> mostly just offering for a look before I push.
>
> -Sara
>
> Ref: https://bugs.php.net/bug.php?id=17400
> Ref: https://github.com/php/php-src/compare/master...weltling:17400
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] C++-like function-try-block proposal

[Niklas Keller]

Hey,


> I have been referred to this mailing list by
> https://wiki.php.net/rfc/howto
> as the first step to propose a language change.  I first tried to register
> on wiki.php.net as per php-src/README.SUBMITTING_PATCH in order to
> actually
> make an RFC, only to be given an error:
>
>   Writing /srv/web-wiki/dokuwiki/conf/users.auth.php failed
>

Should be fixed now, please retry.

Regards, Niklas

Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates

[Niklas Keller]

>
> I just pushed support for security_level [1] which is more comprehensive
> and the patch is also very simple.
>
> Apology for such last minute addition but I felt that it is really useful
> for 7.2 and I have already messaged about that and haven't heard any
> objections. Of course if anyone feels strongly against it, I will be happy
> to reconsider it.
>

Unfortunately I forgot about it, but it defaults to 0, which is equivalent
to prior OpenSSL versions. I guess it might make sense for consistency, but
we probably want to raise it to at least "1" in PHP 7.3 or maybe even "2".
OpenSSL's man page explicitly recommends against setting it higher than
"1", but only because of SHA-1, which should be phased out by now.

Regards, Niklas