[spam removed]

The image php:8.1-apache contains an old version of the Apache2 webserver which has several critical vulnerabilities.
CVE-2023-25690 and CVE-2023-27522 which have a CVSS score of 9.8 as well as CVE-2006-20001, CVE-2022-36760 and CVE-2022-37436 which are CVSS rated 9.0.
Please upgrade the Apache2 version asap to the latest version, at least 2.4.56 which is the version all those vulnerabilities had been fixed.
In the same go an upgrade to Debian Bookworm seems required as per https://security-tracker.debian.org/tracker/source-package/apache2 Bullseye seems not to upgrade Apache2 further, except Bullseye-Security does.

PHP-FPM (and CLI) always fails to execute scripts encoded with IonCube 12 with segmentation fault.
I've lost full day trying to find the cause of this issue, tried with different versions of PHP (from 8.1.0 to 8.1.17) and different IonCube Loader (12.0.1 to 12.0.5).
Discovered that issue is present ONLY on php:8.1-fpm image, php:8.1 works fine without segfault.
I guessed that problem is probably in compile configuration flags. Checked what's the difference between php:8.1 and php:8.1-fpm and saw that php:8.1 has flags --enable-phpdbg --enable-phpdbg-readline --enable-embed, which php:8.1-fpm doesn't have.
So I cloned project, added these flags to 8.1/bullseye/fpm/Dockerfile, built image and PHP-FPM stopped failing with encoded scripts.
Don't know what these flags do and why they are not added to FPM image. But I think that they need to be there.

PHP-FPM (and CLI) always fails to execute scripts encoded with IonCube 12 with segmentation fault.
I've lost full day trying to find the cause of this issue, tried with different versions of PHP (from 8.1.0 to 8.1.17) and different IonCube Loader (12.0.1 to 12.0.5).
Discovered that issue is present ONLY on php:8.1-fpm image, php:8.1 works fine without segfault.
I guessed that problem is probably in compile configuration flags. Checked what's the difference between php:8.1 and php:8.1-fpm and saw that php:8.1 has flags --enable-phpdbg --enable-phpdbg-readline --enable-embed, which php:8.1-fpm doesn't have.
So I cloned project, added these flags to 8.1/bullseye/fpm/Dockerfile, built image and PHP-FPM stopped failing with encoded scripts.
Don't know what these flags do and why they are not added to FPM image. But I think that they need to be there.

Djdje

When a container FROM php:8.0-apache is created and hit on port 80 (out of the box) the first result is a 403, probably because there is no default document and DirectoryIndex is prohibited. It would be nice for the developer if there was some sort of default index.html or index.php in /var/www/html so that the out-of-box-experience is a better one, and the developer doesn't have to figure out whether the image is broken or not.

I haven't tried any of the other variants other than the one mentioned above.

I note that building the default nginx image (another provider, I'm sure) comes with a "Welcome to nginx!" page.

Again, just a suggestion, and thanks to the team for all the hard work putting out the image and all it's variants.

Regarding to the issue #1260 I would suggest to add the phpdbg again to ZTS images.
It would be better to add it for all images again but ZTS is at least no FPM image

The workarround

COPY --from=php-cli /usr/local/bin/phpdbg /usr/local/bin/

will also not help in this case

Hey,
this is what I get when building based on top of the newest images. Tried it with "7.1-apache" and "7.2-apache":

➜  main git:(master) ✗ docker build .
Sending build context to Docker daemon  6.144kB
Step 1/14 : FROM php:7.2-apache
 ---> 929cf9eb65b0
Step 2/14 : RUN apt-get update
 ---> Using cache
 ---> 813e0c926fcd
Step 3/14 : RUN a2enmod rewrite
 ---> Using cache
 ---> e6e974456f23
Step 4/14 : RUN a2enmod headers
 ---> Using cache
 ---> c1ee828e99ff
Step 5/14 : RUN docker-php-ext-install pdo_mysql
 ---> Running in 61200b576c4b
+ cd pdo_mysql
+ phpize
Configuring for:
PHP Api Version:         20170718
Zend Module Api No:      20170718
Zend Extension Api No:   320170718
+ ./configure --build=x86_64-linux-gnu
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc
checking whether the C compiler works... no
configure: error: in `/usr/src/php/ext/pdo_mysql':
configure: error: C compiler cannot create executables
See `config.log' for more details
The command '/bin/sh -c docker-php-ext-install pdo_mysql' returned a non-zero code: 77

Any ideas what this could be?

Hello,

I just came across the PR #1259 and the issue #1257 after wondering why the phpdbg has suddenly disappeared from images like php:7.4-fpm-alpine3.14.

While I understand the point of "It is not suitable to debug fpm processes" the images can still be used with the PHP CLI, and thus, having the need for the phpdbg component. In our case we use the production build to run all tests and generate code coverage, and only install dev dependecies on start of the container. We also use the fpm image to run async workers without fpm started)

The use of phpdbg allows faster tests and not having to instal xdebug specifically for this (which would slow drastically any process).

Leaving it will not impact any existing user as it does not provide (AFAIK) any slowness when not used and will save people time, headache, and allow easier testing.

Thanks

Hi
We are seeing a number of Linux kernel vulnerabilities in our images after the ECR scan. We tried to update the images but the Linux kernel vulnerabilities persist. What will be the impact of these on our applications? I am attaching the screenshot of these vulnerabilities.

Issue are Like image file name not found when edit click redirect to edit form. Image file name no show but other value are show don't why happened and also same add new for that's aslo show error move directly upload no found
When check on console forbidden 404status no such file that's

Hey,

It seems generally recommended that tini (or any init-manager) is PID1 inside of a container.

I understand, that php-fpm is already some kind of process manager, but i wonder if there might still be edge-cases where a child-process might become a zombie (where tini would help because it would reap the zombie-process as far as i understand). A quick search for "php-fpm zombie" reveals, that this can be an issue (although such search results seem quite old).

For docker, tini is a popular choice which has base-images and alpine packages. It's also already integrated with docker.

So i guess my question is: is there any specific reason the php images are not using tini/a init process? If not, would it make sense to update the images to include tini?

Thanks.

Hello guys, firt off all is a pleasure for my to put an issue in this repository, So lets go to the issue, recently I'm trying to migrate my old PHP apps deployed on Cpanel the platform which has been choosen to do this migration was Railway app, actually railway app is pretty cool and easy to use. So What is the problem? , In some services in that case I'm using PHP Slim Micro framework, So I've updated my framework fix some stuff (line codes) and test in my local enviroment, of course I tested my API with (PHP 8.2) php -S locahost:8001, in that case works fine, To work with railway app I have to options: 1. Deploy native php (Nix container) or 2 deploy docker, So I've decided to use docker, but I have an issue PHP Slim needs a .htcaccess file to work fine over apache, for that reason to run my container I use php:8.2-apache, So whats is my issue when I put the .htaccess file all my API routes doesn't work.

My docker file is this :

FROM php:8.2-apache

COPY /src /var/www/html

EXPOSE 80

My .htaccess have this:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]`

My index.php have this:

use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Slim\Factory\AppFactory;
use Slim\Routing\RouteCollectorProxy;

require __DIR__ . '/vendor/autoload.php';
$app = AppFactory::create();
$app->setBasePath("");

$app->get('/test', function (Request $request, Response $response) {
  $response->getBody()->write(json_encode(array('getted succesfully')));
  return $response
    ->withHeader('Content-Type', 'application/json')
    ->withStatus(200);
});
$app->post('/test', function (Request $request, Response $response) {
  $body = $request->getParsedBody();
  $response->getBody()->write(json_encode($body));
  return $response
    ->withHeader('Content-Type', 'application/json')
    ->withStatus(200);
});

$app->run();

My scafolding is this:

/src
----/vendor
----composer.json
----composer.lock
----.htaccess
----index.php

Yes the index.php file and .htaccess must to be in the same folder.

So when I run my container with the htaccess file I allways get the error 404 in any single route.

I have attached two images of localhost:8000 (docker instance running) and localhost:8001 (php "native" run), My cuestion is There is any rigth way to put an own .htaccess file into this container.

port 8000 docker instance runnign

port 8001 native instance running

see https://externals.io/message/119551#119553

Currently running docker-ext-install results in a ton of tar warnings that might or might not have an effect on the resulting build:

+ docker-php-ext-install -j 12 exif
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.provenance'

Hello there!

Today we release a few PHP updates containing Security fixes that we are strongly advising users to upgrade to.

Is there a way to trigger your scripts, so we can get the images up to date?

Thanks!

I run

docker pull php:8.2.2-cli-alpine3.17

Get

Error response from daemon: Get "https://registry-1.docker.io/v2/library/php/manifests/sha256:91d91db35bea7a1e2d497d79dba709c37d5e38e82907c5310d8a57b5f9769cd8": EOF

In Debian bullseye this bug was recently fixed: https://security-tracker.debian.org/tracker/CVE-2022-32221

But curl 7.74.0-1.3+deb11u5 is not in the image yet, could you trigger a rebuild of the bullseye images?

Hi folks, I have the next issue with the last Alpine3.15 version
On the next Dockerfile that use the latest alpine version:

FROM php:7.4-fpm-alpine
RUN apk update && apk add freetype-dev \
        jpeg-dev \
        libpng-dev \
        libwebp-dev \
        libzip-dev nginx
RUN docker-php-ext-install bcmath mysqli zip
RUN docker-php-ext-configure gd --with-jpeg --with-webp --with-freetype && docker-php-ext-install -j$(nproc) gd

The mysqli extension isn't added to the loaded modules, is missing on the php -m output. But if i force the alpine version to the 3.14 it works as expected. using :

FROM php:7.4-fpm-alpine3.14

maybe related docker-php-ext-installer-issue?

Hi, the apache <2.55 has a critical vulnerability (CVE-2022-36760). Please update all apache based php container. Thanks!