Add a validator to check that PHP-TUF's Composer integration is present and configured correctly

Updated the IS with the proposed resolution.

Neither Automatic Updates nor Project Browser should have a hard dependency on PHP-TUF.

Core may require php-tuf when we merge in. @phenaproxima do you foresee and problems with this? I assuming we don't have any dependencies in php-tuf that core would not want to have an indirect dependency on, like we currently have in Au with composer/composer

Assigning to @phenaproxima for feedback on my idea in MR

Also setting to needs work because even if we don't decide to do any of the ideas I proposed I think at the very least we need to be clear in the messages the security implications. Probably also with @todo to follow-up issue that will provide a link to docs

@tedbow and @tim.plunkett discussed the plan for getting Automatic Updates, Project Browser and Package Manager into core. We're likely going to aim to land Package Manager first. So postponing this issue for now, until the dust settles on that.

RE: 🌱 [policy, no patch] How much of The Update Framework integration is needed for alpha-level review/commit of Package Manager? Needs review

We need TUF for package manager to get into core at all.

from this issues summary

(since we don't need to require TUF for attended Package Manager operations).

We should confirm that with a question in #3349368. It may be the case that all package manager operations need TUF or at least AutoUpdates and Project Browser.

Bumping to critical per #29. But … is this even actionable? Isn't this hard-blocked on #3325040: [Packaging Pipeline] Securely sign packages hosted on Drupal.org using the TUF framework and Rugged → ? 🧐

The current MR needs to be redone anyway, because it's still targeting 8.x-2.x.

P.S.: I think

We need TUF for package manager to get into core at all.

should be

We need TUF for package manager to get into core at all , after all.

😓

re #3284443-11: Enable unattended updates → I am removing unattended update blocker tag as I propose we don't block this in contrib only. But it is still an alpha target because we would need this in core for alpha

Re the current action that is needed is to make a new MR against 3.0.x from the current 8.x-2.x MR

I think we need "Needs issue summary update" before we do more work on this because of the changes made after this comment

re

I would prefer 2) because it would mean that by default all stages would enforce TUF validation. you would have to override this to opt of validation. Otherwise every stage has to opt-in for actual TUF enforcement and not just a warning.

We need to get confirmation from core committers that it is ok for modules building UIs to opt out TUF protect for their use case.

The reason I think it should be ok is otherwise if we make it too difficult to opt-out then I could see developers trying to do this by just removing our validator service altogether. That would be very bad because it would turn off TUF for all use cases

#35: Did we get that clarity? I don't see it on 📌 Add a validator to check that PHP-TUF's Composer integration is present and configured correctly Fixed ? 🤔

@Wim Leers on #36 you linked back to this issue. Did you mean to link to 🌱 [policy, no patch] How much of The Update Framework integration is needed for alpha-level review/commit of Package Manager? Needs review ?

Yes 🙈

First round of review! This is looking great already 😊

re-assigning to @phenaproxima until tests pass

Reflecting that this is hard-blocked on 🐛 StageBase::stageDirectoryExists() breaks on PreCreate Fixed .

Detailed review posted. Chief concern: this should behave more like \Drupal\package_manager\Validator\ComposerPatchesValidator, at least the way it is implemented since 📌 Reliably support cweagans/composer-patches in Package Manager & Automatic Updates: validate stage Fixed .

🐛 StageBase::stageDirectoryExists() breaks on PreCreate Fixed landed.

Changing title to reflect the reality that TUF is basically always required for use of Package Manager.

Making the title a little more specific, since we're not (yet) adding a hard dependency on PHP-TUF.

Filed 📌 [PP-1] Require PHP-TUF's Composer integration plugin Postponed to actually bring this validator into action.

This looks good, but I will have to give it closer look. Didn't find anything I object to though

Thanks for opening 📌 [PP-1] Require PHP-TUF's Composer integration plugin Postponed . Agreed with landing as much as possible NOW, before the d.o infrastructure side is complete 👍 I expanded the information in that issue.

I did still find a few things to be concerned about, but it's definitely closer now!

Excellent work here, and thanks for bearing with me as I scrutinize every line …

🚢

Just 1 suggestion for test coverage

Works for me

Automatically closed - issue fixed for 2 weeks with no activity.