This could be a feature request, but I'll put it as a bug since "use latest version"

Outside of 8.4 support

8.3.13 was released oct 2024, 8.3.24 was released less than 2 weeks ago. Between the 2 are numerous security fixes.

In T401875#11084327, @DamianZaremba wrote:

This could be a feature request, but I'll put it as a bug since "use latest version"

This "latest version" in this sense is maybe better stated as "use latest builder stack that has been imported in the to WMCS workflow". There is nothing that is actively tracking the upstream and refreshing locally at this point.

Until there is a plan around upgrading the "latest version in tools", what is the suitable mechanism for dealing with vulnerabilities in the available images?

The debian images had (have) backports, as far as I can see the php pack in use doesn't implement any handling of backporting, only increasing the available version in the form of releases.

@DamianZaremba if you believe there is a serious vulnerability in one of the available images, one that can cause security risks to Toolforge or to a tool running on Toolforge, I would create a security task using this form and we'll prioritize the roll out of a new version of the image.

For less severe vulnerabilities, I would create a standard task asking for an upgrade to the available images. We do upgrade those periodically, but we don't have the resources to push an update immediately after it is released upstream, it's likely to take a few weeks/months.

(this appears to be the case with Python, so is perhaps in part to how the pack works)

I double checked if there was a different behaviour for Python builds, but it looks similar: using the "latest" available Toolforge builder image, I get

[builder] Installing Python 3.13.3

While the latest version available upstream is Python 3.13.7.

It will depend on the buildpack itself, some buildpacks allow to install a wider range of versions for the language of choice, some would only support a small range, some also allow to try to install any available version (dotnet iirc) and fail only later if there are any incompatibilities.

I think that if you use .python-version you can still pull 3.13.7 on the current buildpack, though it's not the default, and is newer than the buildpack (looking at https://github.com/heroku/buildpacks-python/blob/v0.26.1/src/python_version.rs#L164 , did not try though, it will complain for python 4.X, or 3.14.X, but patches versions seem ok).

If you put 3.13.7 in .python-version then the build will report Using Python version 3.13.7 specified in .python-version and you get the latest version.

Otherwise you get 3.13.0 which is nearly 1 year old.

It doesn't work with 3.14.0rc2 but that is still in pre-release;

[step-build] 2025-08-20T19:04:38.407504712Z [Determining Python version]
[step-build] 2025-08-20T19:04:38.410318848Z 
[step-build] 2025-08-20T19:04:38.410476605Z [Error: Invalid Python version in .python-version]
[step-build] 2025-08-20T19:04:38.410491254Z The Python version specified in your .python-version file
[step-build] 2025-08-20T19:04:38.410500915Z isn't in the correct format.
[step-build] 2025-08-20T19:04:38.410509666Z 
[step-build] 2025-08-20T19:04:38.410519430Z The following version was found:
[step-build] 2025-08-20T19:04:38.410527909Z 3.14.0rc2
[step-build] 2025-08-20T19:04:38.410926892Z 
[step-build] 2025-08-20T19:04:38.410942897Z However, the Python version must be specified as either:
[step-build] 2025-08-20T19:04:38.410951583Z 1. The major version only: 3.X  (recommended)
[step-build] 2025-08-20T19:04:38.410959821Z 2. An exact patch version: 3.X.Y
[step-build] 2025-08-20T19:04:38.410993708Z 
[step-build] 2025-08-20T19:04:38.411070622Z Don't include quotes or a 'python-' prefix. To include
[step-build] 2025-08-20T19:04:38.411081810Z comments, add them on their own line, prefixed with '#'.
[step-build] 2025-08-20T19:04:38.411089729Z 
[step-build] 2025-08-20T19:04:38.411097884Z For example, to request the latest version of Python 3.13,
[step-build] 2025-08-20T19:04:38.411156220Z update your .python-version file so it contains:
[step-build] 2025-08-20T19:04:38.411187380Z 3.13
[step-build] 2025-08-20T19:04:38.411321769Z 
[step-build] 2025-08-20T19:04:38.411333622Z We strongly recommend that you use the major version form
[step-build] 2025-08-20T19:04:38.411472158Z instead of pinning to an exact version, since it will allow
[step-build] 2025-08-20T19:04:38.411485670Z your app to receive Python security updates.
[step-build] 2025-08-20T19:04:38.412494856Z ERROR: failed to build: exit status 1

This is contrary to the PHP pack which just ignores what you specify entirely.

If you put 3.13.7 in .python-version then the build will report Using Python version 3.13.7 specified in .python-version and you get the latest version.

You're right, I only tried the default and didn't try specifying an exact version. This is a nice feature of the Python buildpack!

This is contrary to the PHP pack which just ignores what you specify entirely.

This could be a feature request for the PHP buildpack maintainers, maybe you could open an issue for them to consider? Until that is implemented, we have to manually update the buildpack version in Toolforge, which we will do every few months, unless there's an urgent security fix that will prompt us to upgrade sooner.

The current version we are using is v0.2.4 which was released 4 months ago.

I think we can try updating the 'latest-versions' builder image to add that support, I still have to do a full battery of tests and such.

[step-build] 2025-08-22T12:49:38.860499727Z [Installing platform packages]
[step-build] 2025-08-22T12:49:39.203935919Z No composer.lock file present. Updating dependencies to latest instead of installing from lock file. See https://getcomposer.org/install for more information.
[step-build] 2025-08-22T12:49:39.204101605Z Loading composer repositories with package information
[step-build] 2025-08-22T12:49:39.438165951Z Updating dependencies
[step-build] 2025-08-22T12:49:39.445148325Z Your requirements could not be resolved to an installable set of packages.
[step-build] 2025-08-22T12:49:39.445217639Z 
[step-build] 2025-08-22T12:49:39.445232170Z   Problem 1
[step-build] 2025-08-22T12:49:39.445244603Z     - Root composer.json requires heroku-sys/php >=8.4, found heroku-sys/php[8.2.19, ..., 8.3.13] but it does not match the constraint.

That range appears to be build from e.g. https://lang-php.s3.us-east-1.amazonaws.com/dist-heroku-24-arm64-cnb/packages.json, which is constructed from https://github.com/heroku/buildpacks-php/blob/v0.2.4/buildpacks/php/src/platform.rs#L51.

In the latest version the repo comes from e.g. https://lang-php.s3.us-east-1.amazonaws.com/dist-heroku-24-arm64-cnb-stable/packages.json which contains the packages up to 8.4.11 (https://github.com/heroku/buildpacks-php/commit/f6a68803e0de595c00884ffd9348fbf84c506564).

It appears you can pass HEROKU_PHP_PLATFORM_REPOSITORIES so I guess that could be set to the new repo url and things would just work on 0.2.4.

I'm not sure how the 'repository snapshots' are generated, but essentially upstream does support pinning versions similar to python, but in 0.2.4 the 'deprecated repo' is being used which does not have the newer versions available in stable.

Given this support already exists upstream, asking them for it is almost certainly going to be met with 'upgrade' as a response.

I'll merge with T380127: [builds-builder] Add support for Heroku's "24" builder stack based on Ubuntu 2024.04 noble as both are fixed the same way.