Re: [PHP-DEV] Wiki Access request

2024-01-21 Thread Ilija Tovilo
Hi Carlos!

On Fri, Jan 19, 2024 at 4:56 PM Barel  wrote:
>
> This page in the Wiki https://wiki.php.net/internals/references has a lot
> of links which are outdated and should be removed or changed. If you can
> provide wiki edit access for me I can work on updating them and also try to
> find more recent links to add to that reference page (suggestions welcome!!)
>
> My username for the wiki site is "barelon" in case this is needed

I can absolutely give you write access to these pages. Updating this
list to reflect more up-to-date resources certainly makes sense.

As you probably know, there are a number of different places where php
internals are documented, and I think that, long-term, it makes sense
to try to consolidate these efforts. We briefly spoke about this in
the last foundation meeting.

We have some documentation in the php-src repository itself, a
significant amount in the php internals book
(https://www.phpinternalsbook.com/), some in the wiki, some on blogs
of current or previous contributors, etc. There are a number of things
that are important when it comes to documentation, like convenience,
access, history, discoverability, etc.

While not the worst, I don't think the wiki is the best place for this
work. Handling documentation directly through Git in PHPs main
repository (or at least a repository in the PHP organization) would
likely tick the most boxes. Providing documentation with PRs might
also improve the understanding of intention of the changes for
reviewers.

As for links to other references, I believe the CONTRIBUTING.md file
is currently the most up-to-date.

https://github.com/php/php-src/blob/master/CONTRIBUTING.md#technical-resources

Rather than duplicating this list on the wiki, it might make sense to
reference the CONTRIBUTING.md file, and extend it as necessary.

Ilija

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



Re: [PHP-DEV] [RFC] Add http_(get|clear)_last_request_headers() function

2024-01-21 Thread Gina P. Banyard
Hello internals,

I have updated the RFC to include a motivation and rejected ideas section:
https://wiki.php.net/rfc/http-last-response-headers

Unless there is further discussion, I intend to open the vote for the RFC on 
Wednesday the 24th of January.

Best regards,

Gina P. Banyard

>

Re: [PHP-DEV] BLAKE3 hash

2024-01-21 Thread tag Knife
That's why I suggested implementing separate length algorithms like we have
for SHA3.

On Fri, 19 Jan 2024 at 21:03, Hans Henrik Bergan 
wrote:

> Having looked into it, it seems difficult after all,
> I would want a new $options argument for hash_final(), and some
> internal changes to struct php_hash_blake3_ops,
> and that internal change would have to be updated for all other hashes
> PHP support..
> I'm not up for doing that now.
>
> And I think it should be a separate PR, after the initial support gets
> merged.
>
> On Fri, 19 Jan 2024 at 21:42, Hans Henrik Bergan 
> wrote:
> >
> > >BLAKE3 has 2 default sizes
> >
> > Nope, only 1 canonical size, 256 bits.
> > *BUT* BLAKE3 is XOF, it can be exactly as long as you want it to be:
> >
> > $ echo test | b3sum --length 5
> > dea2b412aa  -
> > $ echo test | b3sum --length 10
> > dea2b412aa90f1b43a06  -
> > $ echo test | b3sum --length 32
> > dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2  -
> > $ echo test | b3sum --length 64
> >
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4cca
> >  -
> > $ echo test | b3sum --length 999
> >
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4ccaa32f434df18da6161cabb08b6278dcebca9833fe8d9f65d64db922cecf78c55b521f60dbd77d8ad8378a8f481f2941fedc817d7e1fdeb9c9c9915f3e0a8a8b3cbd4849e21dbe4e359b21224dee5b75bcee0f2083bb8c25559b109727d23b02bde4d2e212529106a1b23be564007909fa23e39c8fdca42a86e75f1568d77a85b0efb0acfa0258907f6d9bfae259234d782d53276f823fe32e29b7165818cbc75e4860188d60f6bb31b00308b1a7293b75e007eaf2de846709bb1856ed398e1c354a093b4f4853b9127ba2e9d85b5336b3e09eb802eef8168f1954c34cc9c61bb933de56790caaff3e03b43f85febfc175e3534e687527a757c2b2e5474efa6db51873da140f5ebc65dca5545b73dd64ac7585fe1d123475e128878962ff8952cd2c8372c4808c4893c8038e6ffb52ef7cf9416ad71588d779c8d60d19c997524b6f756b1d0d5934d41a8e3644fb3fc23e2403bf8b94b95a36f66fb108b6ed824b117f3de9314566bd7042bdd5116e096f0846121ba7034559b234074eac403d2d0f9a4386745375c54d2c22cc970a1cd9836cc9ad1bc3b8c511e5674f05cd5cb8d844c3e802199f0d8b9f3b6e2abd8e830b5768c1539b2d445181fbdcf77c51c330c67aa7b62691d18ecdb7d3124ac4e5fd83a8251ec072740aa4029624ad0a51ebfc8281a5e098ceda2b468e0f936a93b3498b0f11484c4e04cd7be657614ddebe9c08eb0c912431239605e1924009d32afeb965e9c7bbde77bc8efc2ebbc7eb3555286bb7b97fc30fe33806b36aef129d975251a737f0a285fd7cb617b9326211d22924704a2760e235ffa0c125eabb556698120229880b3af0f6dc81336af17fc90f3e889142a5e338a28816c0b6b3944d2f05b7a70189d3e8a19a1e6f6ca0041d4eb165ab4e4aad2f6ec87dc2986263e395c5a5d626bf8847d8b4a70126858f6adda1f39ce0cacf266895856c9ea118418b80c1a37260c7ef73598beb6b2cb3665eece981e249fec4ab8ad2424f1243b0835a7f079a3a9e9c288395a88e70f75eb5610251a416a7189d6e1c3c25a6729d3c9bae65970f8fa48d3ef8f8469ab62c19c3adc04a5c7debea10a910df7d389b183c18cd33fe6b946ebfc5b8a0505968a63122fe0f618e8cf07a978777381bdbafac8024226eee532b76d63ee4a0b45f1f623928afcce21977284868747d7949dd912c8b0894b6a782d2985085f0e629c0c7be7ab19b37e4c5f01a1636f62ee55783b86df8d53698e8b4bbe03fd69322609bb6fdee35cb433d44ec7322d6f1d040f87072bba06ab793bd857c7f754b080b8b04b28c
> >  -
> >
> > And what's more, thanks to PHP8.1.0's new $options argument for hash()
> > we can expose blake3's XOF like
> >  hash("blake3", "test", options: ["length"=>512/8]): blake3_512
> >  hash("blake3", "test", options: ["length"=>256/8]): blake3_256
> >  hash("blake3", "test", options: ["length"=>8/8]): blake3_8
> >  hash("blake3", "test", options: ["length"=>1000]): blake3_8000
> >
> >
> > that shouldn't be too difficult to implement either! good idea
> >
> > On Fri, 19 Jan 2024 at 20:20, tag Knife  wrote:
> > >
> > > On Fri, 19 Jan 2024 at 18:43, Hans Henrik Bergan 
> wrote:
> > >
> > > >  Can we add the BLAKE3 hash?
> > > >
> > > > Created a PR here: https://github.com/php/php-src/pull/13194
> > > >
> > > > BLAKE3 is a very fast ("blazing fast") cryptographically secure
> hash. It is
> > > > the latest iteration of the BLAKE hash, which was a SHA3 finalist~
> see
> > > > https://github.com/BLAKE3-team/BLAKE3 for more info on BLAKE3.
> > > >
> > > > In the PR is a portable C implementation, along with optimized
> ARM-neon and
> > > > x86_64 SSE2, SSE41, AVX2, and AVX512 implementations for GCC+unix and
> > > > GCC+windows and MSVC (*MSVC is currently only using the portable
> > > > implementation, but it should be easy for a developer equipped with
> MSVC to
> > > > enable the optimized implementations. I don't have MSVC personally)
> > > >
> > > > That means the PR includes ~35 copies of the same algorithm, in
> > > > hand-written assembly, optimized for various CPU/compiler/OS
> combinations.
> > > > Which means the PR is hug*e.*
> > > >
> > > > It would be possible to only ship a subset of them (For example,
> keeping
> > > > just the gcc+unix+SSE2 and gcc+unix+AVX2 and ARM-neon and trash the
> rest,
> > > > would benefit a lot systems in-the-wild, and reduce the s

Re: [PHP-DEV] BLAKE3 hash

2024-01-21 Thread Gina P. Banyard
On Monday, 22 January 2024 at 02:29, tag Knife  wrote:
> That's why I suggested implementing separate length algorithms like we have
> for SHA3.

Just an etiquette note, please don't top post on the mailing list. [1]
I have no idea what this sentence is replying to, and it makes following the 
discussion difficult.

Best regards,

Gina P. Banyard

[1] https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md

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



[PHP-DEV] Newly Created Wiki Account - Quick Introduction

2024-01-21 Thread Jair Humberto
Hi Friends,

My name is Jair Humberto, I am brazilian and have been working with PHP
since 2006. I am super excited about the new things PHP has launched lately
and finally realised that I can contribute as well. I think this is a new
fase of my career, I want to learn a bit more about the php source code and
processes and I plan to start contributing with small things, but my first
main goal (long term) is to make possible generics in PHP, one day!

Thank you


Re: [PHP-DEV] BLAKE3 hash

2024-01-21 Thread tag Knife
On Mon, 22 Jan 2024 at 02:43, Gina P. Banyard  wrote:

> On Monday, 22 January 2024 at 02:29, tag Knife 
> wrote:
> > That's why I suggested implementing separate length algorithms like we
> have
> > for SHA3.
>
> Just an etiquette note, please don't top post on the mailing list. [1]
> I have no idea what this sentence is replying to, and it makes following
> the discussion difficult.
>
> Best regards,
>
> Gina P. Banyard
>
> [1] https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md


Yea I forgot to top post that reply. I just quick replied.


Re: [PHP-DEV] BLAKE3 hash

2024-01-21 Thread tag Knife
On Fri, 19 Jan 2024 at 21:03, Hans Henrik Bergan 
wrote:

> Having looked into it, it seems difficult after all,
> I would want a new $options argument for hash_final(), and some
> internal changes to struct php_hash_blake3_ops,
> and that internal change would have to be updated for all other hashes
> PHP support..
> I'm not up for doing that now.
>
> And I think it should be a separate PR, after the initial support gets
> merged.
>
> On Fri, 19 Jan 2024 at 21:42, Hans Henrik Bergan 
> wrote:
> >
> > >BLAKE3 has 2 default sizes
> >
> > Nope, only 1 canonical size, 256 bits.
> > *BUT* BLAKE3 is XOF, it can be exactly as long as you want it to be:
> >
> > $ echo test | b3sum --length 5
> > dea2b412aa  -
> > $ echo test | b3sum --length 10
> > dea2b412aa90f1b43a06  -
> > $ echo test | b3sum --length 32
> > dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2  -
> > $ echo test | b3sum --length 64
> >
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4cca
> >  -
> > $ echo test | b3sum --length 999
> >
> dea2b412aa90f1b43a06ca5e8b8feafec45ae1357971322749480f4e1572eaa2ea67cf3c73a3acbfa2bdab694345d8ecf5e353dd1a3d5a9628aec9bffc3e4ccaa32f434df18da6161cabb08b6278dcebca9833fe8d9f65d64db922cecf78c55b521f60dbd77d8ad8378a8f481f2941fedc817d7e1fdeb9c9c9915f3e0a8a8b3cbd4849e21dbe4e359b21224dee5b75bcee0f2083bb8c25559b109727d23b02bde4d2e212529106a1b23be564007909fa23e39c8fdca42a86e75f1568d77a85b0efb0acfa0258907f6d9bfae259234d782d53276f823fe32e29b7165818cbc75e4860188d60f6bb31b00308b1a7293b75e007eaf2de846709bb1856ed398e1c354a093b4f4853b9127ba2e9d85b5336b3e09eb802eef8168f1954c34cc9c61bb933de56790caaff3e03b43f85febfc175e3534e687527a757c2b2e5474efa6db51873da140f5ebc65dca5545b73dd64ac7585fe1d123475e128878962ff8952cd2c8372c4808c4893c8038e6ffb52ef7cf9416ad71588d779c8d60d19c997524b6f756b1d0d5934d41a8e3644fb3fc23e2403bf8b94b95a36f66fb108b6ed824b117f3de9314566bd7042bdd5116e096f0846121ba7034559b234074eac403d2d0f9a4386745375c54d2c22cc970a1cd9836cc9ad1bc3b8c511e5674f05cd5cb8d844c3e802199f0d8b9f3b6e2abd8e830b5768c1539b2d445181fbdcf77c51c330c67aa7b62691d18ecdb7d3124ac4e5fd83a8251ec072740aa4029624ad0a51ebfc8281a5e098ceda2b468e0f936a93b3498b0f11484c4e04cd7be657614ddebe9c08eb0c912431239605e1924009d32afeb965e9c7bbde77bc8efc2ebbc7eb3555286bb7b97fc30fe33806b36aef129d975251a737f0a285fd7cb617b9326211d22924704a2760e235ffa0c125eabb556698120229880b3af0f6dc81336af17fc90f3e889142a5e338a28816c0b6b3944d2f05b7a70189d3e8a19a1e6f6ca0041d4eb165ab4e4aad2f6ec87dc2986263e395c5a5d626bf8847d8b4a70126858f6adda1f39ce0cacf266895856c9ea118418b80c1a37260c7ef73598beb6b2cb3665eece981e249fec4ab8ad2424f1243b0835a7f079a3a9e9c288395a88e70f75eb5610251a416a7189d6e1c3c25a6729d3c9bae65970f8fa48d3ef8f8469ab62c19c3adc04a5c7debea10a910df7d389b183c18cd33fe6b946ebfc5b8a0505968a63122fe0f618e8cf07a978777381bdbafac8024226eee532b76d63ee4a0b45f1f623928afcce21977284868747d7949dd912c8b0894b6a782d2985085f0e629c0c7be7ab19b37e4c5f01a1636f62ee55783b86df8d53698e8b4bbe03fd69322609bb6fdee35cb433d44ec7322d6f1d040f87072bba06ab793bd857c7f754b080b8b04b28c
> >  -
> >
> > And what's more, thanks to PHP8.1.0's new $options argument for hash()
> > we can expose blake3's XOF like
> >  hash("blake3", "test", options: ["length"=>512/8]): blake3_512
> >  hash("blake3", "test", options: ["length"=>256/8]): blake3_256
> >  hash("blake3", "test", options: ["length"=>8/8]): blake3_8
> >  hash("blake3", "test", options: ["length"=>1000]): blake3_8000
> >
> >
> > that shouldn't be too difficult to implement either! good idea
> >
> > On Fri, 19 Jan 2024 at 20:20, tag Knife  wrote:
> > >
> > > On Fri, 19 Jan 2024 at 18:43, Hans Henrik Bergan 
> wrote:
> > >
> > > >  Can we add the BLAKE3 hash?
> > > >
> > > > Created a PR here: https://github.com/php/php-src/pull/13194
> > > >
> > > > BLAKE3 is a very fast ("blazing fast") cryptographically secure
> hash. It is
> > > > the latest iteration of the BLAKE hash, which was a SHA3 finalist~
> see
> > > > https://github.com/BLAKE3-team/BLAKE3 for more info on BLAKE3.
> > > >
> > > > In the PR is a portable C implementation, along with optimized
> ARM-neon and
> > > > x86_64 SSE2, SSE41, AVX2, and AVX512 implementations for GCC+unix and
> > > > GCC+windows and MSVC (*MSVC is currently only using the portable
> > > > implementation, but it should be easy for a developer equipped with
> MSVC to
> > > > enable the optimized implementations. I don't have MSVC personally)
> > > >
> > > > That means the PR includes ~35 copies of the same algorithm, in
> > > > hand-written assembly, optimized for various CPU/compiler/OS
> combinations.
> > > > Which means the PR is hug*e.*
> > > >
> > > > It would be possible to only ship a subset of them (For example,
> keeping
> > > > just the gcc+unix+SSE2 and gcc+unix+AVX2 and ARM-neon and trash the
> rest,
> > > > would benefit a lot systems in-the-wild, and reduce the size of the
> PR
> > > > substantially)
> > > >
> > > > It would also be possible to onl

Re: [PHP-DEV] BLAKE3 hash

2024-01-21 Thread Hans Henrik Bergan
On Mon, 22 Jan 2024 at 07:10, tag Knife  wrote:
>
> That's why I suggested implementing separate lengths of the like we have for 
> SHA3, so we could have BLAKE3_256 and BLAKE3_512 and maybe inbetweens.

we can look into exposing blake3's XOF (arbitrary length) capabilities
after (and if) initial blake3 support gets merged.
would probably look something like hash_final($ctx,
options:["length"=>512/8]); hash("blake3", "x", options:
["length"=>512/8]);
and deserves its own dedicated pull request.

On Mon, 22 Jan 2024 at 03:43, Gina P. Banyard  wrote:
>
> Just an etiquette note, please don't top post on the mailing list. [1]
> I have no idea what this sentence is replying to, and it makes following the 
> discussion difficult.

I see, thanks for the heads up.

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