README

This project aims to help run Drupal projects on secure and high-quality Drupal dependencies.

CHECK OUT the mxr576/ddqg-composer-audit package that extends composer audit command with advisories originating from the ^dev-no-[a-zA-Z]+-versions$ releases.

Releases

Releases of this package that matches the ^dev-no-[a-zA-Z]+-versions$ regex ensure that your project doesn't have installed dependencies with known quality problems.

$ composer require --dev mxr576/ddqg:[dev-no-insecure-versions|dev-no-unsupported-versions|dev-non-d10-compatible-versions]

• dev-no-insecure-versions: Project releases (versions) affected by public security advisories (PSAs), only in currently supported branches of a project.
• dev-no-deprecated-versions:
  • Projects flagged with Obsolete development status by maintainers
• dev-no-unsupported-versions: This was inspired by this thread and it is a list of:
  • Projects flagged with Unsupported maintenance status by maintainers
  • Project releases (versions) from unsupported branches
  • Project releases that are not covered by the Drupal Security Team
• dev-non-d10-compatible-versions and dev-non-d11-compatible-versions: For Drupal 9/10 projects respectively, prevents installation of package versions that are not Drupal 10/11 compatible. It can make the Drupal 10/11 upgrade more painless.
  • Warning: This is only ~99% accurate because core compatibility information sometimes cannot be identified from the information available on Update Status API. compatible. See Github Actions logs for skipped projects/versions.
• [PLANNED] An opinionated list of projects that should be avoided

Should you depend on both dev-no-insecure-versions and dev-no-unsupported-versions and at the same time?

YES, you should. The dev-no-insecure-versions only contains version ranges affected by a PSA if they are in a supported branch by maintainers. When a branch becomes unsupported, related version ranges disappear from this list. The reasoning behind this implementation is that if a branch is not supported by maintainers (neither covered Drupal Security Team) then your biggest problem is not depending on a version that has known PSA (which may or may not be leveraged on your project) but the fact that your project depends on an unsupported version.

TODOs

• Ignore releases with Drupal 7 compatibility as there is no plan to support Drupal 7