Skip to content

Add FrankenPHP to sapi credits#1

Open
alexander-schranz wants to merge 5 commits into
dunglas:frankenphp-8.2from
alexander-schranz:patch-2
Open

Add FrankenPHP to sapi credits#1
alexander-schranz wants to merge 5 commits into
dunglas:frankenphp-8.2from
alexander-schranz:patch-2

Conversation

@alexander-schranz

@alexander-schranz alexander-schranz commented Oct 18, 2022 •
edited
Loading

Copy link
Copy Markdown

This allows us to use:

RUN php -r 'echo phpinfo();' | grep FrankenPHP

To check in Dockerfile in FrankenPHP php-src is used.

PHP-SRC PR: php#9777

@dunglas

dunglas commented Oct 18, 2022

Copy link
Copy Markdown
Owner

php -i frankenphp already does the trick as it's the name of the SAPI.

We could add credits to phpinfo() but this must be done in the frankenphp.c, not in a fork of php.

@alexander-schranz

alexander-schranz commented Oct 18, 2022

Copy link
Copy Markdown
Author

php -i frankenphp already does the trick as it's the name of the SAPI.

Where do I see it here?

We could add credits to phpinfo() but this must be done in the frankenphp.c, not in a fork of php.

Sounds good.

dunglas pushed a commit that referenced this pull request Feb 8, 2023
@MaxKellermann
ext/opcache/zend_jit: call TSRM dtor before unloading opcache.so (php…
131b862 
…#10533)

Commit a211956 added a TSRM destructor, but that destructor
will get called by tsrm_shutdown(), which is after opcache.so has
already been unloaded, resulting in a shutdown crash, e.g.:

  #0  0x00007fad01737500 in ?? ()
  #1  0x000055ac54e723c4 in tsrm_shutdown () at TSRM/TSRM.c:194
  php#2  0x000055ac54c42180 in main (argc=80, argv=0x55ac57bc14d0) at sapi/cli/php_cli.c:1388

By calling ts_free_id() before opcache.so gets unloaded, we can easily
fix this crash bug.
dunglas pushed a commit that referenced this pull request Mar 4, 2023
@TimWolla
password: Use php_random_bytes_throw in php_password_make_salt (p…
c59e075 
…hp#10393)

The CSPRNG failing should be rare nowadays, but it *might* happen and without
this patch it's hard for the user to find out why the salt generation failed:
The error message is not actionable.

This patch will automatically set the CSPRNG exception to the `$previous`
exception of the ValueError that is thrown, allowing the developer to determine
the cause of the salt generation failure.

Before:

    Fatal error: Uncaught ValueError: Unable to generate salt in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}
      thrown in php-src/test3.php on line 3

After:

    Fatal error: Uncaught Random\RandomException: Cannot open /dev/urandom: No such file or directory in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}

    Next ValueError: Unable to generate salt in php-src/test3.php:3
    Stack trace:
    #0 php-src/test3.php(3): password_hash(Object(SensitiveParameterValue), '2y')
    #1 {main}
      thrown in php-src/test3.php on line 3
dunglas pushed a commit that referenced this pull request Dec 16, 2024
@devnexen
ext/gmp: gmp_pow fix FPE with large values.
d70b781 
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
dunglas pushed a commit that referenced this pull request Dec 16, 2024
@devnexen
ext/gmp: gmp_pow fix FPE with large values.
e0a0e21 
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```

close phpGH-16384
dunglas pushed a commit that referenced this pull request Dec 17, 2024
@Ma27 @ndossche
ext/soap: fix make check being invoked in ext/soap
73c4fa0 
On NixOS we run `make` & `make check` inside `ext/soap` which broke the test
like this:

    001+ Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'ext/soap/tests/gh15711.wsdl' : failed to load "ext/soap/tests/gh15711.wsdl": No such file or directory
    002+  in /build/php-8.3.13/ext/soap/tests/gh15711.php:29
    003+ Stack trace:
    004+ #0 /build/php-8.3.13/ext/soap/tests/gh15711.php(29): SoapClient->__construct('ext/soap/tests/...', Array)
    005+ #1 {main}
    006+   thrown in /build/php-8.3.13/ext/soap/tests/gh15711.php on line 29

Fix is to make the path dependant on `__DIR__` as it's the case in other
testcases including WSDLs.

Closes phpGH-16733.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Extension: standard

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@alexander-schranz @dunglas