Require the php intl extension and drop the symfony polyfill dependency

This is a great initiative, especially given the recent CVE on symfony/polyfill-intl-idn.

Drupal core never calls any intl functions directly - they are only used internally by Symfony packages (symfony/string, symfony/mime, egulias/email-validator), so the polyfills are purely transitive dependencies.

Proposed approach:

1. Add "ext-intl": "*" to core/composer.json.
2. Add the three symfony/polyfill-intl-* packages to the replace section of the root composer.json, mirroring how symfony/polyfill-php72 through php85 are already handled.
3. Remove the three pinned entries from composer/Metapackage/CoreRecommended/composer.json.
4. Add 'intl' to $required_extensions in SystemRequirements.php.
5. Update composer.lock.

ext-intl is already enabled by default in most PHP distributions and hosting environments, so the impact on existing installations should be minimal.

We could also use ext-intl directly where relevant, rather than just relying on it transitively through Symfony. For instance, Unicode normalization via \Normalizer::normalize() or IDN handling via idn_to_ascii() / idn_to_utf8() in email/URL validation. That would make the requirement more justified and reduce indirect coupling with Symfony internals

ext-intl is already enabled by default in most PHP distributions and hosting environments

Do you have a source for this information?

Hmm no, my bad, I'm so used to ext-intl being enabled in the environments I work with that I probably made a false claim. I just quickly checked some official PHP 8.x Docker images do not include it by default (docker-php-ext-install intl is required explicitly).

Yeah, I'm not sure it's available everywhere, which is why I asked - I think this would make Drupal harder to install for some users, and it's the reason the polyfill exists in the first place.

To me this is a bit of a kneejerk reaction to Symfony's most recent update and policy on fixes; historically we have never had problems with this (or any other polyfill), so next time this happens it's just as likely to be some other Symfony component causing the trouble.

Given the lack of issues we've had with the polyfills (until now) and the fact they are all indirect dependencies (I think?) perhaps we should just loosen the constraints on them in core-recommended from the ~ operator to the ^ operator.

Maybe we shouldn't have purely transitive dependencies in core-recommended at all? If we don't explicitly use them ourselves, it shouldn't matter which version we pick; we should be able to trust upstream's judgement.

+1

I see there are now 3 symfony packages and 5 twig packages with a vulnerability advisory. For nimbleness and ease, those should be fixable without having to go through the release process of core each time.

Agreeing with #8 on the principle - purely transitive dependencies that core doesn't explicitly use probably shouldn't be pinned in core-recommended.

However, doing this without first requiring ext-intl as suggested by catch leaves a risk: polyfill major versions can introduce behavioral differences on edge cases (Unicode normalization, IDN handling, etc.). A contrib or custom module that implicitly relies on that behavior could silently regress when the version changes, with no obvious paper trail. The risk for the broader ecosystem is non-zero.
That said, requiring a php extension that core only uses transitively - solely to protect third-party projects from a hypothetical regression - seems hard to justify.
Any module relying on intl functions should declare the dependency itself - either symfony/polyfill-intl-* or ext-intl - in its own composer.json. Relying on core pulling it in transitively is a packaging defect, not core's responsibility.

#8 alone seems fair enough

There were issues updating the core to highly critical version update for both the versions: 10 and 11 https://www.drupal.org/project/drupal/releases/10.6.9

    - Root composer.json requires drupal/core-recommended 10.6.9 -> satisfiable by drupal/core-recommended[10.6.9].
    - drupal/core-recommended 10.6.9 requires symfony/polyfill-intl-idn ~v1.37.0 -> found symfony/polyfill-intl-idn[v1.37.0] but these were not loaded, because they are affected by security advisories ("PKSA-dwsq-ppd2-mb1x"). 

The issue got fixed after updating to the higher versions 10.6.10 and 11.3.11
Thanks team for quick turn around fix!