WordPress Advisories for WP Core Providers

[LeoColomb]

I'm opening this thread on behalf of the @roots project.
We recently were asked how to reflect WordPress advisories properly as a Composer package wrapper for WordPress core.
This also aligns with the question raised years ago here: #383

While we all agree linking the advisories to the packages is a great idea, there are some challenges:

1. The best would probably be to be able to set an alias for advisories on Packagist for every/any WP core provider.
   • But WordPress is not officially referenced as a Composer package.
     That is the purpose of the WP core provider packages, stating the obvious here. The point is that WP advisories, even if registered on GitHub Advisory DB, are not handled by Packagist nor registered in a Composer-compatible name (org/name).
   • Also such feature is not implemented on the Packagist side anyway.
2. Then we could consider implementing automation between WP advisories and the FriendsOfPHP/security-advisories repo.
   • But multiple packages are providing WordPress core.
     Just for @roots, there are 2 packages aligned with the WP core variants. Other projects are also doing mostly the same. It would not be sustainable to duplicate WP advisories to each WP core provider.
3. Then we could consider syncing WP advisories with the packages' repositories (example).
   • But the WP core is obviously WP.org "intelectual property" in the way the packages are and should only be a helper for Composer to download the said IP. They do not host the said IP.
     Syncing advisories with the package repositories would not make sense.
   • Also such implementation would not be easy considering the GitHub Advisory API.
   • And still not very sustainable for the same reasons as in point 2.

At least 2. feels doable, and that's mainly why I'm raising the question here.
But would it be reasonnable?
All in all, do you have any recommendations?

[stof]

• It would not be sustainable to duplicate WP advisories to each WP core provider.

this is exactly what Symfony, Contao and other projects that expose both their mono-repo and their subtree split packages on packagist are doing in this repo: they duplicate the advisory for the mono-repo package and the actual impacted package.

If you have a script generating those advisories anyway, the duplication will not have a maintenance cost.

[LeoColomb]

Thanks for your reply, @stof.
I understand your point, but I'm not sure the comparison fits completely.
Symfony and the others are handling their own IP advisories, with a single and delimited ("actual impacted package") duplication.
That is precisely 2 of the 3 challenges I'm mentioning.

• \2. => Single and delimited duplication is fine, but do we want 10 and growing complete duplication?
• \3. => Handling your stuff/your IP is fine. This is not the case with WP core providers.

If you have a script generating those advisories anyway, the duplication will not have a maintenance cost.

That's fair. Is there a good template for such a script we can use?
Who should be the owner of this script?

[glaubinix]

A bit late here but as an alternative. If this "script" can run without human intervention/supervision, e.g. a clear mapping of GitHub advisories, exposed via their GraphQL API, to package names then it should also be possible to directly integrate this into Packagist.

Keep in mind thought that the GraphQL query that Packagist runs only fetches GitHub verified/reviewed advisories, which means there is a significant delay between advisory publication and appearance in Packagist.