Expand the ability of module maintainers to mark a particular release as security.

Created on 28 June 2024, about 1 year ago
Updated 2 July 2024, about 1 year ago

Problem/Motivation

There are certain cases where a module release is security oriented but does not fall under Drupal's security advisory policy.

This most commonly happens with third party libraries.
I believe the policy is currently that a security release requires a security advisory.

This issue came to light from the polyfill io domain supply side attack.
The security team release the following PSA
https://www.drupal.org/psa-2024-06-26 β†’

This was extremely helpful as it alerted me to the issue.
However near the end of the PSA there was this line:

 As this relates to 3rd party libraries, the Drupal Security Team will not be issuing Security Advisories for these projects and work has been done in the public issue queues (note this may not be a complete list of all affected projects).

with this link: https://www.drupal.org/project/issues/search?issue_tags=polyfill.io β†’

I was surprised to see the webform module's update was not marked as a security release even though the extra info calls it out as security related:

Improve security of polyfill.io Library

It would be beneficial for users of the webform module to be informed that this update has security implications even if they do not subscribe to security updates.

In order to ensure clients are secure I need to monitor that list indefinitely to see if any new modules are tagged with polyfill.io and then see if they provide an update.

Steps to reproduce

N/A

Proposed resolution

Allow certain releases to be tagged as security even without a security advisory.

Remaining tasks

Discuss policy update

User interface changes

N/A

API changes

N/A

Data model changes

N/A

πŸ“Œ Task
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States nicxvan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @nicxvan
  • πŸ‡ΊπŸ‡ΈUnited States nicxvan
  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    I understand that the security team has a large load, but in cases like this a blanket polity of marking these releases as security would help the community at large and I think improve the secure reputation Drupal enjoys.

  • πŸ‡ΊπŸ‡ΈUnited States cmlara

    +1 for allowing maintainers tho self-indicate an issue has security fix concerns when the module is either not covered by the DST or the DST has declined to issue an SA.

    For context I have had 3 incidents in the past year related to the Two-factor Authentication (TFA) module with internal faults that were unable to be marked as security releases:
    Access Bypass Through Replay Attacks β†’
    Authentication bypass when default plugin is not configured β†’
    Replay and Denial of Service vulnerability in HOTP plugin β†’

    None of these were "Drupalgedon" level exploitable however TFA is a security solution module and site owners expect it to enforce second factor authentication.

    Module maintainers may not always be right when they determine a release is not a security fix, however when a maintainer determines a release is a security fix we should generally trust them as the experts of their module to understand the fix does indeed pose a security risk.

  • πŸ‡§πŸ‡ͺBelgium BramDriesen Belgium πŸ‡§πŸ‡ͺ

    +1 I don't see any reason why we should not give this option to a maintainer.

    For webform the impact is fairly limited as we don't seem to use the "chosen" component on any project in case of the Polyfill breach, but yeah, just seeing the update as a "regular" update is not a good way to have people being pushed to update.

Production build 0.71.5 2024