Problem/Motivation

Follow-up to #3612247: Update guzzlehttp/guzzle to 7.15.1 and guzzlehttp/psr7 to 2.12.3 and #3600889: Remove some minor constraints from core-recommended. I think we should make the same change we made on 11.4.x to 11.3.x and 10.6.x so that we don't have to make off-schedule patch releases for our security branches every couple of weeks or more frequently.

Steps to reproduce

Proposed resolution

Short term:

Remove the minor constraints from core-recommended for Symfony polyfills, Twig, and Guzzle

Longer term (#3606820: Add a separate release process for core-recommended):

Add a separate release process for core-recommended.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3612448

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

catch created an issue. See original summary.

sense-design’s picture

sense-design
sense
Primary language German
Location Münster
commented

+1 for this, very annoying to wait for a Drupal core release because of external security fixes eg guzzlehttp

sense-design’s picture

sense-design
sense
Primary language German
Location Münster
commented
Related issues: +#3603733: Update guzzlehttp/psr7 to 2.12.1 and guzzlehttp/guzzle to 7.12.1

longwave made their first commit to this issue’s fork.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Needs review

longwave opened merge request !16396

longwave opened merge request !16397

godotislate’s picture

godotislate
he/him
commented
Status: Needs review » Reviewed & tested by the community

MR diffs for 11.3.x and 10.6.x look essentially the same as the commits to main, 11.x, and 11.4.x, which is expected.

lgtm.

catch’s picture

catch
he/him
Primary language English
commented

For reference:

https://github.com/advisories/GHSA-h95v-h523-3mw8 was fixed only in 7.15.1

Guzzle 7.15.0 was released 5 days ago https://github.com/guzzle/guzzle/releases#release-7.15.0

Guzzle 7.14.0 was released two weeks ago https://github.com/guzzle/guzzle/releases#release-7.14.0

Guzzle 7.13.0 was released three weeks ago https://github.com/guzzle/guzzle/releases#release-7.13.0

Guzzle 7.12.0 was released four weeks ago https://github.com/guzzle/guzzle/releases?page=2#release-7.12.0

karimbou’s picture

karimbou commented

agreed

ashetkar’s picture

ashetkar commented

How to proceed with upgrade 11.3.12 to 11.3.14 ?

When attempting to update to Drupal core-recommended 11.3.14, Composer fails dependency resolution because core-recommended 11.3.14 requires guzzlehttp/guzzle ~7.12.1, but all resolved candidates (7.12.1, 7.12.2, 7.12.3) are blocked by security advisories.

This makes the update path fail even with update-with-all-dependencies.

Root composer.json requires drupal/core-recommended 11.3.14 -> satisfiable by drupal/core-recommended[11.3.14].
drupal/core-recommended 11.3.14 requires guzzlehttp/guzzle ~7.12.1 -> found guzzlehttp/guzzle[7.12.1, 7.12.2, 7.12.3] but these were not loaded, because they are affected by security advisories ("PKSA-fy2t-3c5f-827y", "PKSA-qxvb-2bpp-dnk6", "PKSA-bbs6-q5q9-f3t4", "PKSA-bcdd-5xc7-gwfb", "PKSA-pwsk-hy21-4gby").

Expected result:
Composer should be able to resolve dependencies for Drupal core-recommended 11.3.14 without requiring users to ignore security advisories.

Actual result:
Composer cannot resolve because the required Guzzle constraint (~7.12.1) is fully blocked by advisories in the active policy feed.

ressa’s picture

ressa
he/him
commented

@ashetkar: Did you try the workaround in #3612247: Update guzzlehttp/guzzle to 7.15.1 and guzzlehttp/psr7 to 2.12.3? It might be a temporary fix, until a new version is released.

nojj’s picture

nojj commented

we are on 11.3.14 (drupal/core-recommended ) and the workaround from https://www.drupal.org/project/drupal/issues/3612247
does not work

Problem 1
    - Root composer.json requires guzzlehttp/guzzle 7.15.1 as 7.12.1 (exact version match), found guzzlehttp/guzzle[7.15.1] but these were not loaded, likely because it conflicts with another require.
  Problem 2
    - Root composer.json requires guzzlehttp/psr7 2.13.0 as 2.12.1 (exact version match), found guzzlehttp/psr7[2.13.0] but these were not loaded, likely because it conflicts with another require.
  Problem 3
    - drupal/core-recommended is locked to version 11.3.14 and an update of this package was not requested.
    - drupal/core-recommended 11.3.14 requires guzzlehttp/guzzle ~7.12.1 -> found guzzlehttp/guzzle[7.12.1, 7.12.2, 7.12.3] but it conflicts with your root composer.json require (7.15.1 as 7.12.1).
  Problem 4
    - drush/drush is locked to version 13.7.1 and an update of this package was not requested.
    - drush/drush 13.7.1 requires guzzlehttp/guzzle ^7.0 -> found guzzlehttp/guzzle[7.0.0, ..., 7.15.1] but these were not loaded, likely because it conflicts with another require.
catch’s picture

catch
he/him
Primary language English
commented

@nojj https://www.drupal.org/project/drupal/releases/11.3.16 is released which should allow you to update without workarounds.

This issue should allow updates without there having to be a Drupal core release every time.

nojj’s picture

nojj commented

@catch Thank you! update worked perfectly.

ashetkar’s picture

ashetkar commented

@catch - Thank you. I'm able to update to 11.3.16.
But why core 11.3.15 version is not there?

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

11.3.15 was mis-tagged, we can't revoke a tag once it has been created, so we skipped that and released 11.3.16 instead.

ashetkar’s picture

ashetkar commented

Thank you for info. @longwave.

catch’s picture

catch
he/him
Primary language English
commented

In slack @xjm suggested issuing a PSA for this. To make a start on that, I've added a change record here: https://www.drupal.org/node/3613159

quietone’s picture

quietone commented

I change record is well written and easy to understand. I made one change to the link to the 'how to' page.

quietone’s picture

quietone commented

Although, the polyfills aren't mentioned in the change record.

catch’s picture

catch
he/him
Primary language English
commented

I didn't mention the polyfills because they're indirect dependencies, and because they're polyfills there should never be API changes etc., only bugfixes (although then, why all the minor releases but that's a different problem), and because contrib/custom code will never interact with them directly. Don't mind adding to them but it seemed clearer to only mention twig/guzzle.

  • catch committed d30e4429 on 10.6.x 
    task: #3612448 Widen constraints in core-recommended for 11.3.x and 10.6...

  • catch committed ecffa56f on 11.3.x 
    task: #3612448 Widen constraints in core-recommended for 11.3.x and 10.6...
catch’s picture

catch
he/him
Primary language English
commented
Version: main » 10.6.x-dev
Status: Reviewed & tested by the community » Fixed

Committed/pushed to 11.3.x and 10.6.x respectively, thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

seworthi’s picture

seworthi commented
Status: Fixed » Active

I believe this just broke the version of core composer pulls in. 1 hour mins ago, my sites were fine w/ composer update, as it was using 11.3.16. 35 mins ago, each site started updating core on 'composer update' to update to drupal/core to 11.3.x-dev

I have not changed my composer.json

catch’s picture

catch
he/him
Primary language English
commented

@seworthi what is the minimum stability in your composer.json set to?

seworthi’s picture

seworthi commented

"minimum-stability": "dev"

This is because several modules we need only have dev releases.

catch’s picture

catch
he/him
Primary language English
commented

How long has this composer update pipeline been running?

My guess is that something like the following occurred:

1. The pipeline was previously not updating anything because the core-recommended constraints prevented updating to this guzzle security release https://github.com/guzzle/guzzle/releases/tag/7.15.2 via composer's security blocking feature (which is relatively new)

2. This issue got committed, removing those constraints

3. Now the composer update can update guzzle, and it also updated core to dev because of minimum-stability: dev

If something like this is the case, then the only reason the pipeline hadn't already updated core to a dev release is because of the unreachable Guzzle security release.

Rather than using minimum-stability: dev, you can require individual dependencies with @dev.

seworthi’s picture

seworthi commented

This is what the composer update does, as of 1 hour ago. Every site is currently running 11.3.16. (as you can see, no guzzle update)
Updates:
drupal/core (11.3.16) to (11.3.x-dev)
drupal/core-recommended (11.3.16) to (11.3.x-dev)
drupal/core-composer-scaffold (11.3.16) to (11.3.x-dev)
twig/twig (v3.27.1) to (v3.28.0)
symfony/polyfill-php85 (v1.37.0) to (v1.41.0)
symfony/polyfill-php84 (v1.37.0) to (v1.38.1)
symfony/polyfill-mbstring (v1.37.0) to (v1.38.2)
symfony/polyfill-intl-normalizer (v1.37.0) to (v1.38.0)
symfony/polyfill-intl-grapheme (v1.37.0) to (v1.41.0)

This is our commits from Friday (as you can see, Guzzle was not being blocked from going to 7.15.2)
drupal/core (11.3.14) to (11.3.16)
drupal/core-recommended (11.3.14) to (11.3.16)
drupal/core-composer-scaffold (11.3.14) to (11.3.16)
symfony/yaml (v7.4.14) to (v7.4.15)
symfony/var-dumper (v7.4.14) to (v7.4.15)
symfony/validator (v7.4.14) to (v7.4.15)
symfony/string (v7.4.13) to (v7.4.15)
symfony/serializer (v7.4.14) to (v7.4.15)
symfony/routing (v7.4.13) to (v7.4.15)
symfony/polyfill-php83 (v1.38.2) to (v1.41.0)
symfony/mime (v7.4.13) to (v7.4.15)
symfony/mailer (v7.4.14) to (v7.4.15)
symfony/http-kernel (v7.4.14) to (v7.4.15)
symfony/http-foundation (v7.4.14) to (v7.4.15)
symfony/filesystem (v7.4.11) to (v7.4.15)
symfony/event-dispatcher (v7.4.14) to (v7.4.15)
symfony/error-handler (v7.4.14) to (v7.4.15)
symfony/dependency-injection (v7.4.14) to (v7.4.15)
symfony/console (v7.4.14) to (v7.4.15)
guzzlehttp/psr7 (2.12.5) to (2.13.0)
guzzlehttp/guzzle (7.12.3) to (7.15.2)

catch’s picture

catch
he/him
Primary language English
commented

What are your constraints for drupal/core and drupal/core-recommended?

edit: actually I'm not sure this matters if minimum-stability is dev. I would try setting the individual projects that need dev releases to use @dev and then switch to minimum-stability: stable.

seworthi’s picture

seworthi commented

"drupal/core-composer-scaffold": "11.3.*",
"drupal/core-recommended": "11.3.*",

This is to keep us on 11.3 for now until we finishing testing 11.4. This has been like this for months

It also worth noting, this is for core-dev, which is still on 11.3.16
"require-dev": {
"drupal/core-dev": "11.3.*",

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Fixed

I'm moving this back to fixed, please try setting minimum-stability: stable and then requiring individual projects with @dev where necessary.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

ressa’s picture

ressa
he/him
commented

I agree with @catch that it's best to set the version explicitly for each contrib module, after running into a similar version problem recently. I had less control over versions that I liked in a project, because I thought lowering the composer.json minimum-stability to dev was the way to go. But this affected all versions, Drupal core, contrib modules, etc.

I learned from @jaypan in https://www.drupal.org/forum/support/post-installation/2026-01-30/using-... that it's best to keep minimum-stability at stable, and override it for the individual module by explicitly setting the version for example with composer require drupal/field_group:^4.1@alpha. Since it's not a widely known feature, I added a tip in the Using Composer to Install Drupal and Manage Dependencies documentation page about this.

benjifisher’s picture

benjifisher
he/him or they/them
Primary language English
Location Boston area
commented
Issue summary: View changes

I am copying the Proposed resolution from #3600889: Remove some minor constraints from core-recommended (filling in the link to #3606820: Add a separate release process for core-recommended).