Posted by tuyuri 8 hours ago
If only we could come up with a way to manage memory automatically. Alas, one can only dream.
In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...
# docker pull matomo:latest
latest: Pulling from library/matomo
Digest: sha256:6e63589d31ec653f78e029084d21488640fdbbd9a42c96c872098f42c8678a02
Status: Image is up to date for matomo:latest
docker.io/library/matomo:latest
# docker run --rm matomo:latest php --version
PHP 8.4.26 (cli) (built: Oct 21 2026 00:31:19) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.26, Copyright (c) Zend Technologies
with Zend OPcache v8.4.26, Copyright (c), by Zend Technologies
I'm currently waiting for a new docker image for another project, and their maintainer noticed the old PHP versions in the freshly built images and is still waiting or working on releasing a new container build.
"Let's use this packaging some rando on the Internet built" is a strategy that is exactly as good as it seems, but that's the Docker ecosystem for you.
Packagers who actually understand the software put in good work to package that software in small and well maintained packages. Use them instead!
FROM debian:...
RUN apt install php ...
$ docker pull wordpress:fpm && docker image inspect wordpress:fpm --format '{{.Created}}' && docker run --rm wordpress:fpm php --version
fpm: Pulling from library/wordpress
Digest: sha256:c6d271a445510a3e08cfcc487750ac014f4464165ad6df6356da04680be8e907
Status: Image is up to date for wordpress:fpm
docker.io/library/wordpress:fpm
2026-10-21T01:27:06.695704995Z
PHP 8.3.35 (cli) (built: Oct 21 2026 00:33:17) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.35, Copyright (c) Zend Technologies
with Zend OPcache v8.3.35, Copyright (c), by Zend Technologies
Some systems and services still only allow for one owner though (I'm not going to name names), which can be a big problem when MFA is mandated. From what the poster I responded to said, I'd be very surprised if that were the case for them though - just slightly daft policy.
Proprietary apps are a pita.
I've found that to be incredibly true in my career.
And if the answer is no, well, then Bob just got Hotel California'd and can check out but can never leave.
Help Bob; help yourself.
Implemented a lot of “just in case” policies after that, which seemed obvious but oh well.
Not everything needs hyper security. Heck, I've given AI access to spend money on websites and my only restriction is that the websites limit the daily spend(website side... Although I guess a rogue AI could have changed it... )
https://codeberg.org/oerdnj/deb.sury.org/issues/145#issuecom...
https://launchpad.net/~ondrej/+archive/ubuntu/php/+builds?bu...
Note I want it to work with the backports too, not just the latest version.
Going to migrate the box to Debian in-place. (Or Gentoo, the way things are currently going.)
I realised that my linode and ovh vm's point at local mirrors not direct to ubuntu, I guess that's why the delay
Edit: Linode just updated its mirror.
It would not be easy (or reasonable) to take a public build like that private to build a 'secret' image version, and I'm not sure GitHub even has the capability to do that. I would not trust a build pushed to Docker Hub separate from the established / public / auditable process they have in place.
All dependent (official) images need to go through the same process, so that makes it fairly problematic, and I think Docker needs to take a look at it for the future.
It should definitely have a 'high impact' workflow that bypasses some of those manual steps.
they are wanting people to pay for the hardened version.
`[00:06:03.209] pecl install -f amqp igbinary redis imagick` :sad_face:
Disclosure: I'm a PHP core team member and also contributed some code to PIE.