- Issue created by @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.