doctrine/annotations is abandoned

We deprecated annotations already, but for removal in Drupal 13. https://www.drupal.org/node/3522776

The only remaining annotations usages in Drupal 11 are in some migrate plugins (which are going to be removed in Drupal 12) and the bc layer for annotations.

For Drupal 11, I think our only option is to fork Doctrine Annotations and un-abandon it to suppress the warning, we've had to fork entire dependencies before (for the Zend/Laminas change iirc).

For Drupal 12, we have #3400121: Allow opt-out of annotation parsing to make annotation discovery opt-out, we could also make it opt-in or bring forward the Drupal 13 removal to Drupal 12, although that would need an announcement and it would need to be announced quickly.

As @berdir pointed out in that issue the security surface is minimal, the main issue is support for newer PHP versions, which could get worse the further into Drupal 12's release cycle we are.

Moving this to critical, while we will end up with the same code running or not running, it would be good to resolve this asap especially since this is likely to lead to lots of duplicate reports.

We forked parts of Doctrine already by copying them into core namespaces, so I think the simplest solution is to do that for the remaining classes that we use.

As the author of some of that code: you could also delete some code after forking, after all Drupal only ever supported class annotations in proper PSR namespaces.

Copied all the classes that we use into core; DocParserTest still passes locally, let's see if anything else is broken. Unsure if we should copy any other tests from Doctrine.

Once again I am surprised that this is green so easily.

I can draft a change record. (https://www.drupal.org/community/contributor-guide/task/write-a-change-r... )

Draft: https://www.drupal.org/node/3551049

Something is amiss, the link for the CR in #10 is a 404 for me. I searched the change records as well and didn't find one for this.

Let's try to add some backward compatibility via moved_classes and/or class_alias().

Draft: https://www.drupal.org/node/3551049

This is a 403 for me. And I don't see a link the CR in the sidebar here.

YesCT might have administer node permission or something on d.o and mixed up the draft and published checkboxes, has happened before as. Someone else with enough permissions should able to publish it while keep it a draft?

Published the change record node (but not the change record itself)

Hello,

Thank you very much for the work.

For those who might be interested, I’m attaching a patch that includes the current changes from the MR !13433 (core directory only).

You can't patch composer dependencies, there is no point in using (or uploading) patch files here. Nothing is broken, nothing is insecure, this is just critical exactly because a lot of people are going to be asking questions about this and we want it resolved quickly. Ignore the warning and stay tuned.

Right now we are auditing composer to fail on abandoned packages. Is the Drupal security team's assessment that it is safe to skip this error on our validation/audit steps in CI?

Added a BC layer for AnnotationException, and updated the change record.

I am not sure we should provide BC for anything else here. If you were depending on doctrine/annotations, and you required it in composer.json: your code will still work. If you were depending on doctrine/annotations as a transitive dependency of core, I am not sure that is core's responsibility to fix.

I compared the Drupal\Component\Annotation\Doctrine\* classes and to Doctrine\Tests\Common\Annotations\* 2.0.2 classes and confirmed that the code is essentially identical.

BC for exception looks good. Also, if this is backported to D10, I think the CR alone is enough without any BC.

LGTM.

Discussed with @catch and we would like to backport this to 10.6 as well.

FYI, I saw Audit: add option to ignore individually abandoned packages #12572 https://github.com/composer/composer/pull/12572 was just merged.

This looks good but it needs a rebase.

Rebased, back to RTBC.

Committed/pushed to 11.x and cherry-picked to 11.3.x, thanks!

Moving to 10.6.x for backport.

doctrine/annotations is still in the composer.lock, which is causing test failures on HEAD #3554820: HEAD testing is broken.

Committed the follow-up, PHPStan is happy in the latest branch job now.

10.6.x is locked to doctrine/annotations 1.14.4, so should the Drupal forked classes in 10.6.x be copies of that version instead of 2.0.2?

I think this should be cherrypicked to 11.3.x too

@godotislate not too sure it matters given we are changing the namespaces anyway, can't remember what the break was between annotations 1 and 2. Also not sure what to do about the exception BC layer though as that isn't supported in the same way in D10.

Attempted a backport to 10.6 on MR 13610 using doctrine/annotations 1.14.4, but ran into some phpstan issues. Will have to loop back later to investigate.

I thought I'd cherry-picked to 11.3.x but apparently not, done now.

Fixed the PHPStan issues, but tests are failing on the 10.6 MR.

https://git.drupalcode.org/project/drupal/-/merge_requests/13610#note_61... for 10.6 is ready.

@catch re: #42 I think the 11.3.x commit might not have been pushed. Maybe it happened during the Gitlab maintenance period?

@godotislate, thanks for making the 10.6 MR

Is the 10.6 MR good to go to RTBC?

10.6 MR looks good to me. We could class_alias() the exception if we think it's worth it, but unsure if that comes with any risks if doctrine/annotations is still installed for some reason.

Hi, why is this merge into branch 11.x, but is not on the latest releases? like 11.2.8 https://git.drupalcode.org/project/drupal/-/blob/11.2.8/composer.lock?re...

Composer audit flags the package doctrine as deprecated, which is a security issue, and it has the value critical.
Is there any planned release with this change?

A deprecated package is not a security issue; it is a warning that the package will become unsupported in the future. We have deliberately not made this change in 11.2 because there is a chance it will break existing sites and we try to avoid that as much as possible in patch releases. It will be released with 11.3.0 in December.

Committed/pushed to 10.6.x, thanks!

Thank you for the explanation @longwave

Published the change record.

In case folks are waiting for the releases,
and to follow-up on my previous comment https://www.drupal.org/project/drupal/issues/3550917#comment-16323381

If folks' CI was blocking them, I wanted to share that people can add to composer.json

        "audit": {
            "ignore-abandoned": ["doctrine/annotations"]
        }

But I also want to note that, I recommend also adding a followup issue to some internal tracker (not d.o) to also remove that workaround once the d.o core releases come out. Which by looking at https://www.drupal.org/about/core/policies/core-release-cycles/schedule#... I'm guessing will be "Week of December 8, 2025 (UTC)"