Changes

[tuutti]

No idea how to title this, but I started investigating how to use composer audit for Drupal modules and started building a tool to generate a similar SA database as https://github.com/FriendsOfPHP/security-advisories, but it ended up requiring way more effort than it was worth due to limited Drupal security advisory metadata.

I have refactored it to generate a similar composer.json as this tool instead and I'm opening this pull request to see if you'd be interested.

It should be much faster because it leverages concurrency (the whole build takes 1-2 min) and fetches the version data from updates.drupal.org, so the constraints should be much simpler/cleaner.

See:

• 9.x composer.json: https://github.com/tuutti/drupal-security-advisories/blob/9.x/composer.json
• 7.x composer.json: https://github.com/tuutti/drupal-security-advisories/blob/7.x/composer.json
• Example build on Github actions: https://github.com/tuutti/drupal-security-advisories/actions/runs/3755418880/jobs/6380461640

You can test this yourself with:

php console.php build:composer current and php console.php build:composer 7.x.

[webflo]

Wow, thanks for the PR. Thats a lot of work :) 👍

I will look at generated file more thoroughly. There is at least a bug for drupal/core in https://github.com/tuutti/drupal-security-advisories/blob/9.x/composer.json#L31. The constraint does not support multiple supported releases. <10.0.2 will flag all older releases an insecure, even if 9.5.2 is perfectly valid. I think each constraint needs a "lower boundary" to avoid invalidation of previous releases.

Regrading composer audit, please check out https://github.com/webflo/drupal-security-advisories-api this repo contains a small symfony api which provides the api for composer audit.

(Ahh your are already in the related d.o issue: https://www.drupal.org/project/project_composer/issues/3301876)

[webflo]

Sorry, i think my last comment about the invalid constraint is wrong.

[Bladedu]

I find this patch really interesting! I tried it myself and it seems it works as expected.

[webflo]

The constraints are simpler, but also a bit more fragile and could lead to false positives. The problem is described in commit: tuutti@ef44ea7. Drupal core released version "9.5.2" and this version was flagged as insecure until the package has been rebuild.

This means that the package must always be up to date, so far I build it only on Wednesday (18-22 UTC) and once on Thursday (to make sure that no security release was missed).

Please correct me if I am wrong. Thanks!

[tuutti]

I think you are right. The upper bound probably should to be capped to latest known release number in that constraint group, like >9.5.1,<=9.5.2 or >2.0.1,<=2.5.0.

[IT-Cru]

Could it maybe interesting to work together with https://github.com/mxr576/ddqg-composer-audit to provide a composer audit plugin extension for the hole Drupal community?

Output with enabled ddqg-composer-audit plugin

composer audit
Found 2 security vulnerability advisories affecting 2 packages:
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core                                                                      |
| CVE               | DDQG-insecure-drupal-core                                                        |
| Title             | The installed version is insecure. (Reported by Drupal Dependency Quality Gate.) |
| URL               | https://www.drupal.org/project/core                                              |
| Affected versions | >=9.4.0,<9.4.14|>=9.5.0,<9.5.8|>=10.0.0,<10.0.8                                  |
| Reported at       | 2023-04-20T22:39:51+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+
+-------------------+----------------------------------------------------------------------------------+
| Package           | guzzlehttp/psr7                                                                  |
| CVE               | CVE-2023-29197                                                                   |
| Title             | Improper header name validation in guzzlehttp/psr7                               |
| URL               | https://github.com/advisories/GHSA-wxmh-65f7-jcvw                                |
| Affected versions | >=2.0.0,<2.4.5|<1.9.1                                                            |
| Reported at       | 2023-04-19T18:25:53+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+

[mxr576]

@IT-Cru I do not know how did you find my tool... but good catch... :D The first public release went live yesterday evening and I haven't promoted it anywhere yet :)

Feel free to use it as inspiration, other than a hobby project, my goal was building a tool that fulfills my current needs (and maybe also our company needs) better than this package as of today. (See also #29)

[tuutti]

Oh yea, I totally forgot about this.

I've refactored this to take supported branches into account, so the maximum/minimum version should be less fragile now. It also means that versions that are not supported are now marked as insecure.

We've been using this as a part of our test CI pipeline for ~3 months now and it seems to work pretty well.

[tuutti]

This is probably no longer needed since the original issue is now fixed (https://www.drupal.org/project/project_composer/issues/3301876). Closing.