Implement “list security advisories” Packagist/Composer API

Related: Interesting work by @mxr756:

• https://github.com/mxr576/composer-audit-changes (MIT-licensed)
• https://github.com/mxr576/ddqg-composer-audit (MIT-licensed)

We are going to have to be a bit better for getting the versions affected populated for contributed modules.

And we only added one value for versions affected, so advisories affecting both 7-compatible and current-Drupal-compatible do indeed have a metadata problem. What we can do now is only support current-Drupal-compatible, only publishing security advisory data at https://packages.drupal.org/8

Looks like if this issue were fixed in drupal packaging, then RenovateBot automatic updater might automatically start picking up security releases. (See the renvoatebot issue I made: "Renovate does not recognize Drupal security releases as security updates".)

An initial example of this is at https://drupal:drupal@packages.staging.devdrupal.org/files/packages/8/p2.... You can add https://drupal:drupal@packages.staging.devdrupal.org/files/packages/8 as a repository to composer.json to test.

The versions affected is sparsely populated for contrib security advisories and is not yet processed, even as a test.

Correction - https://drupal:drupal@packages.staging.devdrupal.org/8/packages.json is the repository to add to test.

At least Composer 2.5.2 is required to get security advisories like this.

Hand reviewed the files and they appear to be well formatted for core. Composer agrees.

As noted before we are unable to review contrib.

Thanks for the reference in #9, I'll also keep an eye on this one: https://github.com/mxr576/ddqg/issues/6

This would be a great improvements for Drupal packages.

After the recent TFA security release, I wonder, if the related advisory is missing or not: https://packages.staging.devdrupal.org/files/packages/8/p2/drupal/tfa.json

Our staging server is behind production by a few days. And under the hood, the json from packages.drupal.org is static files on disk, written as part of release packaging. This does not regularly happen on staging, since new releases & commits are not made there, except for testing. Once https://www.staging.devdrupal.org/security has the new advisory, rebuilding the file can be triggered manually.

packages.staging.devdrupal.org is only for testing and should not be treated as a pre-release, preview, or anything reliable.

We also need to add updating packages.drupal.org after a security advisory update, like is done for releases. So when the affected versions or other metadata in the advisory is updated, packages.drupal.org is also updated.

We also need to add updating packages.drupal.org after a security advisory update, like is done for releases.

This is now done: https://git.drupalcode.org/project/drupalorg/-/commit/328fb19e9f435789bb...

This is now fully deployed and packages.drupal.org metadata, for core and contrib, should be updated within the next hour.

The metadata for all packages which had a security release compatible with Drupal 8 or later has been updated.

Any followups should be new issues for this project or https://www.drupal.org/project/infrastructure → and we’ll triage from there.

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

Does this work as intended?

I have a Drupal 10.1 site currently warning me on its admin/reports/updates page that Simple Menu Permissions 2.0.0 is an unsupported module, and that I should upgrade it to version 2.1.0.

composer audit doesn't mention this at all. Seemingly it either knows nothing about unsupported modules, or else doesn't deem them worth mentioning.

I'm pretty sure the old drush sec and/or drush upc --security-only commands gave the same information that admin/reports/updates is telling me, but those drush commands have been removed in favour of the seemingly-oblivious composer audit command.

I'm pretty sure that it is by design that composer audit only considers SAs. Merely becoming unsupported is out of scope. You could make your own composer or drush command that considers the support status of a module.

Can anyone verify that, please? If that's true (and going to remain this way) then we'll clearly want drush to restore the perfectly functional command it already had for this.

(Which will be pretty unfortunate, because developers everywhere will already have removed that drush command from their CI configs on account of CI breaking when the command was removed, and nothing is going to force them to notice when it is restored.)

@mxr576 has created two plugins that can help with that:

Enrich composer audit with unsupported releases: https://packagist.org/packages/mxr576/ddqg-composer-audit
Prevent composer deploying unsupported releases: https://packagist.org/packages/mxr576/ddqg

You might also look at composer outdated "drupal/*" to get a list of packages that have available non-security updates.

(Thanks for the mentioning :) )

Indeed the Composer plugin and other related solutions were borned to address other kind of project dependency quality challenges than depending on packages with public SA-s, like depending on unsupported packages.
Yeah... The plugin may abusing a bit Composer Audit's original concept, but still seemed a right move to integrate these quality checks with composer audit.

We are actively using these solution integrated to our stack at Pronovix: https://www.linkedin.com/posts/dezsobiczo_dx-php-technicaldebt-activity-...

https://github.com/composer/composer/issues/8272 is the Composer issue for getting “supported” versions into Composer itself. The tricky thing is that “supported” can mean different things across projects.

Moshe: Regarding drush again (having now noted that you're a primary maintainer of that)...

I've tested reversing https://github.com/drush-ops/drush/pull/5775 in order to run drush sec against my codebase (after reinstalling the outdated version of the module via composer), and can see that I was incorrect in suggesting that drush sec had indicated outdated modules (and so I presume there's no benefit in restoring that code specifically).

My recollection of drush ups (pm-updatestatus) from older versions was partly accurate, though: Drush 8's pm.drush.inc and updatestatus.pm.inc show a broad range of status values it can associate with a project. However the --security-only option looks like it would have ignored unsupported modules.

I've been under the misapprehension that drush sec essentially did the same as drush ups --security-only, and that they'd both treated unsupported modules as at least potential security risks (which I think they should do -- a module which is unsupported cannot be expected to receive security patches, even if it contains the identical vulnerable code which was been disclosed and fixed in the supported versions of the module). It's also worth noting that admin/reports/updates treats unsupported modules as Errors in terms of severity, so there's really quite a disparity between the different information sources here.

Given that I cannot see any way in modern drush to list those details (pm:list looks like the only likely command in Drush 12, and it has no such options), it feels to me like a step backwards to ever have removed the pm:updatestatus functionality. Surely we want drush to be capable of providing the same information that the web UI shows at admin/reports/updates?

The deprecation message for pm-updatestatus says "Please see composer show and composer outdated" (in line with the earlier suggestion to use composer outdated "drupal/*"), but that command tells us nothing about support status, so it's not actually a replacement. For my example module it only tells me "patch or minor release available - update recommended"; and composer show drupal/simple_menu_permissions likewise has no understanding of the support status.

My vote would be to restore the pm:updatestatus command in some form, regardless of what may or may not be done with composer, and to provide options for listing known-insecure and unsupported modules. Drupal already knows how to generate that information, so to me it only makes sense to make use of that.

Drush core has happily outsourced codebase assembly and audit to Composer. This makes Drush more maintainable. It is wins like these that have helped Drush thrive for more than 15 years.

I think efforts are better spent on getting Composer to work as you want. See #32. If you don't care to help issue that along, then use the composer extensions mentioned in #29, or make a contrib Drush command.

I do appreciate the benefits of deferring to other tooling; I just think it was jumping the gun to remove the supported-module functionality before composer provided any equivalent. It's great that there's an upstream composer issue in progress which will ultimately fill the gap, but it's approaching 5 years since that issue was raised, and that is not an especially unusual lifespan for software issues generally (and nor is twice that duration for that matter), so IMHO a slightly more conservative approach to removing features would be justified.

I think efforts are better spent on getting Composer to work as you want. See #32. If you don't care to help issue that along, then use the composer extensions mentioned in #29, or make a contrib Drush command.

Noted, thank you.