Problem/Motivation
guzzlehttp/psr7 has a 2.12.1 release with an SA: https://github.com/guzzle/psr7/security/advisories/GHSA-vm85-hxw5-5432.
guzzlehttp/guzzle has a 7.12.1 release with two SAs: https://github.com/advisories/GHSA-wpwq-4j6v-78m3 https://github.com/advisories/GHSA-cwxw-98qj-8qjx
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3603733
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:
Comments
Comment #2
godotislateComment #3
godotislateSo there's a 2.12.1 security release now: https://github.com/guzzle/psr7/security/advisories/GHSA-vm85-hxw5-5432, so going to update branches to that.
Comment #5
godotislateThe deprecations are actually coming from within the guzzle client itself. Resolving those would involve updating guzzlehttp/guzzle (and guzzlehttp/promises), which is probably out of scope here since it's likely this will need to be backported for the security updates. For now, suppressing the deprecations.
We can update guzzlehttp/guzzle in a follow up for main and 11.x (and maybe 11.4?).
Comment #12
godotislateComment #13
godotislateMRs for main, 11.x, 11.4.x up. I explored going forward with updating guzzlehttp/guzzle for main, but while that fixed the deprecations in guzzlehttp/psr7, in introduced deprecations in Drupal test code because of the use of getConfig(): https://github.com/guzzle/guzzle/issues/2514, so going to kick that to a follow up after all.
MRs for 11.3.x and 10.6.x up as well if we want to do patch releases for them. The SA is not on Packagist yet, but we could possibly have the commits ready for a patch release in preparation.
Comment #14
godotislateComment #15
godotislateThere's been discussion on Slack based on #3599842-48: guzzlehttp/psr7 needs to be updated to >2.10.2 to fix 2 security issues whether to relax the core/composer.json constraint back to what it was before the security updates, while leaving the core-recommended and composer.lock changes in place.
Comment #16
godotislateOK, relaxed the constraints for 11+ to ^2.8.0 and 10.6.x to ^2.4.5, which is what they were before the recent updates.
Comment #17
godotislateMissed yesterday that the client library guzzlehttp/guzzle had marked its new 7.12.1 as a security release as well. Will add that here after all.
And today all the SAs have hit composer:
Comment #18
godotislateComment #19
godotislateOK, ready again.
Comment #20
alexpottThe deprecation
%Since guzzlehttp/guzzle 7\.11: Passing null to request option "headers\.Cookie" is deprecated; guzzlehttp/guzzle 8\.0 requires string|non-empty-array\.%Is only coming from a test. Hiding the deprecation makes things harder - if we make \Drupal\Tests\rest\Functional\CookieResourceTestTrait::getAuthenticationRequestOptions only add
$request_options[RequestOptions::HEADERS]['X-CSRF-Token']if $this->csrfToken is set then we don't need to ignore the deprecation.FYI 11.x is currently failing due to this.
Comment #21
godotislateI was planning on opening a follow up to address all the guzzle deprecations (the cookies one and the
ClientInterface::getConfig()one), but I've updated the MRs per #20. Will create a follow up forgetConfig()later.Comment #22
godotislateComment #23
alexpott@godotislate thanks - this looks great now - I think that when deprecations are coming from test infra it's great to get them don asap so that deprecations in non-test code are surfaced sooner.
Comment #28
larowlanCommitted to main and 11.x
Leaving at RTBC for decisions to back port further
Comment #29
catchIf I understand correctly this is preventing regular composer updates since the CVEs aren't covered by the previous minor releases, in which case this will need to go back to 11.3 and 10.6
Not sureel about 11.2 and 10.5 which are nearly out of support.
Comment #30
larowlanDoing the 11.4, 11.3 and 10.6 backports. Will take a bit because of the phpstan change triggering a check of all files in pre commit hook
Comment #36
larowlanCommitted to 11.4.x, 11.3.x and 10.6.x. In regards to 11.2.x and 10.5.x I guess it depends on when EOL is. Our next core security window is July 17th. If those branches go EOL before them we don't need to backport further.
Comment #38
jamesoakleyThanks for fixing. Does this mean that 11.4.x, 11.3.x and 10.6.x site maintainers need to wait until July 17th before they can have a new core release to fix these upstream security issues? If so, is there a manual way to get composer to update those affected packages before then?
Comment #39
godotislateThe release managers are discussing a plan for doing patch releases soon. By the original calendar, 11.4.0 would have been released this past week, so 11.2 and 10.5 should have gone EOL, but the security releases and out of band patch releases the last couple months have contributed to slight delays of 11.4.
In the meantime, the known workarounds are:
--no-blockingCLI option orCOMPOSER_NO_BLOCKINGenv variable: https://getcomposer.org/doc/03-cli.md#composer-no-blockingconfig.policyblock: https://getcomposer.org/doc/06-config.md#policyNote that the latter two do not update the packages, but they prevent
composer installorupdatefrom being blocked.Related: There is also discussion about relaxing the constraints in
drupal.core-recommended: #3600889: Remove all minor constraints from core-recommendedComment #40
jamesoakleyThank you and I'm following both those related issues already. The aliasing route this time is complicated by the second level dependency on guzzlehttp/promises. Just creating aliases for the two packages being shown in composer audit throws an error that the aliased update can't be installed.