Sync WordPress Core CVE/GHSA Advisories

[michaelbragg]

Summary

Sync the CVE/GHSA advisories from WordPress core to this project.

The project already syncs tags. Would it be possible to include these advisories?

The reason for doing this would be:

• Advisories would surface when a project contains the roots/wordpress dependency, and Composer runs its audit functionality.
• Versions marked with the vulnerability as fixed would bypass any cooldown values set in Dependabot/Renovate, allowing security releases to be integrated more quickly.
• Allow advanced projects to run fully automated upgrades while taking advantage of Composer

Additional context

No response

[dmpinder]

Yes absolutely agree 💯

[retlehs]

This can currently be done with https://github.com/typisttech/wpsecadv

[michaelbragg]

WpSecAdv works well to tell us that there is a problem when we run composer locally or within a CI.

The problem we have seen is that automated dependency management systems will not generate a PR to bypass a cooldown window when WpSecAdv flags an advisory.

These tools will only activated if the advisory is associated with the source repository.

I guess these are doing similar things but for different purposes.

WPSecAdv is for preventing the requiring or adding of insecure versions.

Assigning advisories to this repo would be for automated PR generation to secure versions.

I hope I've managed to explain why the suggestion wouldn't resolve this issue.

We run WPSecAdv on our projects and are still running into this problem.

[LeoColomb]

Thanks for the suggestion, but I'd advocate not to do so.
The main reason against is that Roots Composer packages don't distribute WordPress software per se. The "IP" of WordPress does not leave WP.org. The packages only point to the right WP.org file.
Said differently, a security advisory on Roots repo should be only about the Composer JSON definition, but I don't think we should copy or sync WordPress CVE.

I believe the mentioned package JSON already references the correct source of the distributed software, so security tools & dependency managers should be able to follow.
If there is a change on the Composer JSON to makes things easier/clearer, that is very much welcomed.

@retlehs @swalkinshaw wdyt?

[tangrufus]

Tying WP core advisories to roots/wordpress-no-content & roots/wordpress-full is a good idea.

The question is how.

As @LeoColomb explained, re-creating GHSA advisories under Roots' repos is not ideal. Plus, GitHub doesn't provide a way to mirror advisories. I foresee new GHSA IDs would be issued for the Roots counterparts.

Quick look into packagist.org source code, I don't see a way to claim other packages' advisories.

Possible Solution

Add roots/wordpress-no-content and roots/wordpress-full to wp-packages + serve both their version metadata & advisory lists.

In other words, merge the following JSON files as wp-packages.org/p2/roots/wordpress-no-content.json:

• https://packagist.org/p2/roots/wordpress-no-content.json
• https://repo-wpsecadv.typist.tech/p2/roots/wordpress-no-content.json

However, it comes down to whether your dependency management tools read advisories from Compsoer repos.