Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Over at https://www.drupal.org/docs/updating-drupal/responding-to-critical-secur... the JSON output does not track something like "versions_affected", so there is no way to, for example, ensure something like https://www.drupal.org/psa-2019-02-19 only shows up on 8.5.x and 8.6.x sites. There's data to back this up in the conversation at https://twitter.com/webchick/status/1362569962695446530 about adding this feature to System module.
The lack of this could result in site owners getting irrelevant notices, which they cannot shut off, and which could lead into either widespread ignoring of these messages, or widespread disabling of this feature, both of which work against our goal to increase Drupal's security.
Proposed resolution
Add some metadata in the JSON file to allow the core feature to only show messages that impact the installed core version.
Remaining tasks
1. Figure out if we should do this
2. Propose new JSON property/ies
3. Code it.
4. Update core feature to take advantage of it.
User interface changes
N/A
API changes
Yes.
Data model changes
Yes.
Comments
Comment #2
webchickWe chatted about this in Slack in the thread at https://drupal.slack.com/archives/C7QJNEY3E/p1619714230411400.
@drumm would like security team sign-off before changing the API in any way, which is completely fair.
His main concern was that the more information you give about a forthcoming vulnerability, the more information attackers have to try and exploit it ahead of time.
This is true. However, we seem to give out that information freely on PSAs. Examples:
He also pointed out that in most cases, Drupal 8 / 9 and 9 / 10 security issues impact the other platforms (it's not the same as D7 vs. D8/9 which were two completely different code bases, effectively). This is also true. But yet, we continue to innovate in newer major versions of Drupal to add more features. Some of which might have security issues (in fact, newer code is arguably more likely to). An issue in Olivero theme is never going to impact D8 sites. Neither is a security issue in an API present in D8 that we removed in D9.
Why I'm pushing on this is that we know from user research at https://twitter.com/webchick/status/1362569962695446530 that the #1 reason people push back against a feature like this is their users getting irrelevant notices and this creating work for them. So it seems like an important consideration if we do not want people to shut this off en masse, thus severely hampering the benefit.
Comment #3
webchickComment #4
tedbowI wanted to point that if we add this metadata we don't have to use it on every security advisory.
Just like the Security Team members are in charge now of creating the text in the advisories to determine what information is too much that might given away a vulnerability they would also be in charge adding this metadata or leaving it blank.
For any advisory where the metadata is not specified Core could default to show the advisory
1) Just have major versions affected, the available choices would all major version of Drupal regardless of support(in case we want to push a security fix to major version that was just taken out of support but 10s of thousands of sites are still using
2) A Composer constraint. For example for the release above that has "8.5.x and 8.6.x" in the text the metadata would have been
^8.5 || ^8.6Method 2 would give the most flexibility and even if the Security team wanted a policy of only ever specifying major versions they could still use this method. For example for 9 and 10 but not 8 you could use
^9 || ^10.Probably with the limited number of people who have access to the PSA form on drupal.org you could just have this be enforced by the writers but you could also limit the UI for the field to only show a multi-select of major versions and then translate that into the field value
^9 || ^10. This way though if the policy changed to allow specifying minor version you update the UI on the PSA form to and not need to make any changes to core.Comment #5
tedbowWanted to paste in some of my thoughts from a slack thread with @drumm
@drumm said thinks a D7 only PSA at this point is a near impossibility. I could definitely see why that would be the case because the d7 code base has been around for so long. But "near impossibility" is not impossible.
I think the big risk in this scenario is we have D7 only PSA all D8 and D9 sites seen this dire warning and some get annoyed and turn off this functionality and never see another PSA.
The solution though I suggested in #4 is a lot of work for a near impossibility.
Here is another idea:
version_constraint"is_psa === 1and all other logic determines it should be shown to the site.version_constraintalso workedversion_constraintIf 5) happens, say if there is Drupal 7 PSA that is forth coming drupal.org could handle it in different ways for example.:
drush_drupalorg_update_psa_json()which produces the PSAs to acceptversion_constraint. It would have to pass it for several nids or just only work when only 1 nid is specified.Drupal.org could then use the test json file produces by this change with core's test to make sure they would work.
Comment #6
drummFor any core implementation of this -
When there is a highly critical vulnerability, the timeline is often compressed. The security team will need to announce incomplete information in the PSA in some cases. It would be ideal if we could tell everyone only exactly what they need, but in reality, the messaging can’t always be straightforward.