Problem/Motivation

Symfony has released some security fixes. These are in components that are not used in Drupal core, but we should bump the versions of Symfony anyway to avoid vulnerability checkers from complaining.

Steps to reproduce

https://github.com/symfony/symfony/releases/tag/v6.3.8
https://github.com/symfony/symfony/releases/tag/v4.4.51

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

9.5.x

Symfony components have been updated to v4.4.51. This version contains some security fixes. These are in components that are not used in Drupal core, but could trigger false positives from vulnerability checkers.

Also the composer/composer component has been updated to 2.2.22 to fix a known vulnerability

10.0.x

Symfony components have been updated to v6.3.8 . This version contains some security fixes. These are in components that are not used in Drupal core, but could trigger false positives from vulnerability checkers.

Also the composer/composer component has been updated to 2.6.5 to fix a known vulnerability

CommentFileSizeAuthor
#15 3400841-nr-bot.txt78 bytesneeds-review-queue-bot
#12 5449.diff82.79 KBspokje
#8 5448.diff24.45 KBspokje

Issue fork drupal-3400841

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:

Comments

longwave created an issue. See original summary.

cilefen’s picture

Why v4?

xjm’s picture

@cilefen Because November is a gray area for Drupal 9 support. We end November 1 because Symfony will not commit to whether their security support for their releases ends at the beginning or the end of the month, but regardless it's meant to correspond to the Symfony EOL. So, since Symfony did a release, it's polite of us to provide one as well as the final patch release of D9. There is also precedent for this from D8 in 8.9.20, which was an actual security update for Drupal 8 to correspond with a Symfony update for Symfony 3 released in November 2021.

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

spokje’s picture

StatusFileSize
new24.45 KB
spokje’s picture

Right...

So 9.5.x MRs don't trigger GitLab CI.

Uploaded the diff from the MR as patch to go through Drupal CI (remember that one, you young hipsters?)

I did:

$ composer update symfony/*

Also it makes sense to me to bump composer/composer to deal with https://github.com/advisories/GHSA-jm6m-4632-36hf
(We did that for 10.1.x upwards in #3391991: Security update composer/composer (CVE-2023-43655), which was at backporting status)

$ composer-lock-diff --no-links
+------------------------------------+---------+---------+
| Production Changes                 | From    | To      |
+------------------------------------+---------+---------+
| symfony/event-dispatcher-contracts | v1.1.13 | v1.10.0 |
| symfony/http-kernel                | v4.4.50 | v4.4.51 |
| symfony/polyfill-ctype             | v1.27.0 | v1.28.0 |
| symfony/polyfill-iconv             | v1.27.0 | v1.28.0 |
| symfony/polyfill-intl-idn          | v1.27.0 | v1.28.0 |
| symfony/polyfill-intl-normalizer   | v1.27.0 | v1.28.0 |
| symfony/polyfill-mbstring          | v1.27.0 | v1.28.0 |
| symfony/polyfill-php80             | v1.27.0 | v1.28.0 |
| symfony/var-dumper                 | v5.4.19 | v5.4.29 |
+------------------------------------+---------+---------+

+------------------------+---------+---------+
| Dev Changes            | From    | To      |
+------------------------+---------+---------+
| composer/composer      | 2.2.18  | 2.2.22  |
| symfony/phpunit-bridge | v5.4.19 | v5.4.31 |
+------------------------+---------+---------+
spokje’s picture

Version: 11.x-dev » 10.0.x-dev
Assigned: Unassigned » spokje
Status: Active » Needs work

spokje’s picture

StatusFileSize
new82.79 KB

Nice, 10.0.x doesn't trigger GitLab CI as well...

Diff from MR is patch, did the same as for 9.5.x.

$ composer-lock-diff --no-links
+------------------------------------+---------+---------+
| Production Changes                 | From    | To      |
+------------------------------------+---------+---------+
| symfony/console                    | v6.2.5  | v6.3.8  |
| symfony/dependency-injection       | v6.2.6  | v6.3.8  |
| symfony/deprecation-contracts      | v3.2.0  | v3.4.0  |
| symfony/error-handler              | v6.2.5  | v6.3.5  |
| symfony/event-dispatcher           | v6.2.5  | v6.3.2  |
| symfony/event-dispatcher-contracts | v3.2.0  | v3.4.0  |
| symfony/http-foundation            | v6.2.6  | v6.3.8  |
| symfony/http-kernel                | v6.2.6  | v6.3.8  |
| symfony/mime                       | v6.2.5  | v6.3.5  |
| symfony/polyfill-ctype             | v1.27.0 | v1.28.0 |
| symfony/polyfill-iconv             | v1.27.0 | v1.28.0 |
| symfony/polyfill-intl-grapheme     | v1.27.0 | v1.28.0 |
| symfony/polyfill-intl-idn          | v1.27.0 | v1.28.0 |
| symfony/polyfill-intl-normalizer   | v1.27.0 | v1.28.0 |
| symfony/polyfill-mbstring          | v1.27.0 | v1.28.0 |
| symfony/process                    | v6.2.5  | v6.3.4  |
| symfony/psr-http-message-bridge    | v2.1.4  | v2.3.1  |
| symfony/routing                    | v6.2.5  | v6.3.5  |
| symfony/serializer                 | v6.2.5  | v6.2.13 |
| symfony/service-contracts          | v3.2.0  | v3.4.0  |
| symfony/string                     | v6.2.5  | v6.3.8  |
| symfony/translation-contracts      | v3.2.0  | v3.4.0  |
| symfony/validator                  | v6.2.5  | v6.2.13 |
| symfony/var-dumper                 | v6.2.5  | v6.3.8  |
| symfony/var-exporter               | v6.2.5  | v6.3.6  |
| symfony/yaml                       | v6.2.5  | v6.3.8  |
| symfony/polyfill-php83             | NEW     | v1.28.0 |
+------------------------------------+---------+---------+

+------------------------+--------+--------+
| Dev Changes            | From   | To     |
+------------------------+--------+--------+
| composer/composer      | 2.4.4  | 2.6.5  |
| symfony/browser-kit    | v6.2.5 | v6.3.8 |
| symfony/css-selector   | v6.2.5 | v6.3.2 |
| symfony/dom-crawler    | v6.2.5 | v6.3.4 |
| symfony/filesystem     | v6.2.5 | v6.3.1 |
| symfony/finder         | v6.2.5 | v6.3.5 |
| symfony/lock           | v6.2.5 | v6.3.8 |
| symfony/phpunit-bridge | v6.2.5 | v6.3.8 |
+------------------------+--------+--------+
spokje’s picture

Issue summary: View changes
spokje’s picture

Assigned: spokje » Unassigned
Status: Needs work » Needs review
needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new78 bytes

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

spokje’s picture

Status: Needs work » Needs review
Issue tags: +no-needs-review-bot

Yeah, love you too needs-review-queue-bot...

spokje’s picture

longwave’s picture

Wondering if we should be even more conservative here and only upgrade the affected packages to cover the security warning? Symfony is pretty good at backward compatibility but if we are to do a 10.0.x release here if we can avoid upgrading all components from Symfony 6.2 to 6.3 I think we should. Similarly the polyfills don't really need to be updated unless we are forced by dependencies of the packages with security updates.

We also need a patch (or MR, this time!) here for 10.1.x.

spokje’s picture

Assuming 9.5.x is OK.

For 10.0.x: Not sure we can stay on 6.2.something without actually making changes to the constraints in the composer.jsons. which would make the new core release more strict than the ones before?

Or without doing the changes in the composer.jsons, keeping the composer.lock and then reverse the changes in the composer.jsons.? Which seems like faking/cheating/weird to me.

Anyway, this seems to Need Work from somebody.

spokje’s picture

Status: Needs review » Needs work

Version: 10.0.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

spokje’s picture

I assume this, although deemed critical then, is now outdated and can be closed?

longwave’s picture

Status: Needs work » Closed (outdated)

Since we relaxed the requirements on core-recommended so users could self upgrade to newer patch releases, the security team have stopped receiving notifications and complaints from users running vulnerability scanners, so it looks like we don't need to strictly do this sort of thing any more.

Thanks anyway for your vigilance on these issues!