Include major versions of contrib modules which are marked unsupported

[bradjones1]

Let's say a contrib module moves from having active support of both a 1.x and 2.x branch, but 1.x reaches EOL. Can we include a constraint for ^1? That would allow tools like drush sec to flag these versions as unsupported, even if there is not a corresponding security issue/release prompting its inclusion.

Similar in spirit to #7 but only for branches.

[webflo]

Could you provide an example project?

[webflo]

Example: easy_breadcrumb.

I couldn't find the info about supported branches in drupal.org JSON API. I think we have to use Update Status XML.

https://updates.drupal.org/release-history/easy_breadcrumb/current => supported_branches

[mxr576]

You can also use Admin Toolbar as an example, 3.0.3 is reported as unsupported in Drupal's Updates UI (3.1.0 is available), but currently this tool does not complain about it.

[weitzman]

IMO unsupported is a different and less grave situation than actively insecure status. I dont see enough value in treating them the same. IMO this is wont fix for this project.

[janmashat]

Drupal security advisories appear to treat them the same. And the name of this project is pretty closely tied to those IMO 😉

[bradjones1]

Drupal security advisories appear to treat them the same.

To make this even more complicated, we're talking about two different definitions of "unsupported." The recent slew of advisories marks entire projects "unsupported," and this is I think surfaced in the API as something like revoked or similar... meaning the project had previously opted in to coverage and is no longer maintained, prompting a public notice.

This is different from what is proposed here, which is for branches of opted-in modules to be marked unsupported. For instance, Simple OAuth is removing support from 8.x-4.x at the end of February, but 5.2.x is supported.

[janmashat]

Ahh yes you're right, and there's already an open issue #7 for that...sorry for the noise.

[bradjones1]

IMO unsupported is a different and less grave situation than actively insecure status. I don't see enough value in treating them the same. IMO this is wont fix for this project.

I disagree, though not strongly. I think it would be a "secure" outcome if we could be confident that security releases would flag unsupported branches when they are released, but I am not sure/don't think this is the case. Take for example Simple OAuth module, which I co-maintain:

We are planning to mark unsupported 8.x-4.x and 5.0.x in the next few months. It's highly likely that many users will not upgrade. Let's say there's a security release on 5.2.x; we would not backport the security patch to prior (not unsupported) versions. I'd need to validate what the releases API would show, then; would it mark insecure < 5.2.[security-release], or something like > 5.2.0 < 5.2.[security-release]? If so, that would be a problem b/c users of this repo wouldn't see either of those unsupported branches marked as conflicted.

[mxr576]

If anybody is looking for a solution for this particular problem, let me promote my tool that collects all unsupported packages from Drupal.org every day.

https://packagist.org/packages/mxr576/ddqg#dev-no-no-unsupported-versions

It can be also combined with composer audit to have them reported automatically in CI pipelines.

https://packagist.org/packages/mxr576/ddqg-composer-audit