Require PHP-TUF's Composer integration plugin

Given Drupal core release managers have indicated this is a hard requirement … updating issue metadata accordingly.

This is AFAICT hard-blocked on #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged too. Once #3316617: Add a validator to check that PHP-TUF's Composer integration is present and configured correctly lands, this will be down to PP-1.

#3316617: Add a validator to check that PHP-TUF's Composer integration is present and configured correctly is in.

@phenaproxima Can we already get a patch/MR in place? 🤓

Right, but I mean an outline of a MR that shows which code would need to change. While it's still fresh in your head.

I would not expect this MR to pass obviously!

Splendid! 🤩

Thanks 😊

https://packagist.org/packages/php-tuf/ should mean this is unblocked?

Moving to core.

I think this still might only be partially implemented in package_manager - we need to figure out exactly what's left to do here.

Setting as postponed on upstream https://github.com/php-tuf/composer-integration/issues/127

As discovered in #3477553: [PP-1] Manually test TUF-enabled Composer projects in even basic lab deployments the plug-in causes an excessive increase in memory consumption.

That should be resolved by https://github.com/php-tuf/php-tuf/pull/386 and https://github.com/php-tuf/php-tuf/pull/387 - manual testing of those MRs (or in general if there's a new release incorporating them) would be very welcome. Updating the issue summary to link to them.

https://github.com/php-tuf/php-tuf/pull/395 landed.

#3477553: [PP-1] Manually test TUF-enabled Composer projects is still open, but if the dependency is in core, that is one less testing step.

This is postponed on 3 php-tuf issues and 1 core issue, so changing status. Update the issue to put the postponed items into the remaining tasks per the guidelines.

Is this still postponed on anything?

I think this is still postponed on #3370270: [PP-1] Add php-tuf/composer-integration to core dependencies, which is postponed on #3579174: [meta] Diagnose issues related to TUF-enabled projects. It's hard to confidently test the tooling with the current metadata issues.

Updated status of related Github tickets.

Added blocker on php-tuf/composer-integration#127

https://github.com/php-tuf/composer-integration/issues/127 had some work one on it already, I haven't profiled since my last update on there though and can't remember where it got to. It might be that the memory overhead is low enough that it shouldn't block, at least not inclusion for testing.

For general package_manager performance, #3534109: Permanently maintain a sandbox directory in package_manager is likely to have a lot more impact.

Re. #127, specifically, we plan to profile against the current codebase, then again against a checkout prior to the work that's been merged over the past few months. That should give us a baseline to determine whether additional work in #127 is warranted.

We're also planning to work on #3534109: Permanently maintain a sandbox directory in package_manager, but I think that might be more of a blocker for #3331078: Add php-tuf/composer-stager to core dependencies — for experimental Automatic Updates & Project Browser modules, rather than this issue.

A suggestion was previously made to adopt FAIR: https://git.drupalcode.org/project/infrastructure/-/work_items/3580895. I'm not sure why that issue was made an infra ticket when really the whole point of FAIR would be a non-dependence on D.O. infra. That should play into discussions here on if PHP-TUF is the best choice available. I'm not sure FAIR is necessarily any more or less mature than PHP-TUF.

I haven't read into FAIR all that deeply, but AFAICT, adopting FAIR would mean dropping Composer altogether (and everything that implies), which is outside the scope of this ticket, imo.

Also, according to its [security docs](https://github.com/fairpm/fair-protocol/blob/main/docs/security.md#secur...), FAIR seems to assume some kind of package signing by the repository itself. This is closer to PHP-TUF's role in addressing the [various attack vectors](https://theupdateframework.org/docs/security/) that the TUF Spec was designed to protect against.

which is outside the scope of this ticket, imo.

I believe the scope of this ticket is including PHP-TUF for use by project browser and automatic updates as a secondary security measure on top of composer.

If those modules were migrated to FAIR TUF may become moot.

FAIR seems to assume some kind of package signing by the repository itself

Indeed. I believe it was intended to be a secure distributed supply chain. We would need to understand the signing protocol to understand if TUF is relevant in that environment.

FAIR would mean dropping Composer altogether

From what I understand from Typo3 they are implementing FAIR and keeping composer as an option (at least for now) with FAIR possibly creating a custom repository type in the future to be a part of composer. Yes FAIR was originally envisioned as a package manger for Wordpress which did not generally use composer for management so it does have a different design.

If your not using any of the fancy Project Browser or Auto Update features that is a reasonable deployment for most sites since TUF to my knowledge is not providing any mentionable protection above what already exists with D.O. composer deployments.