Skip to content

Support multiple "equivalent" security releases #34

@jenlampton

Description

@jenlampton

There are currently two secure releases of Backdrop core, 1.12.1 and 1.11.5, as can be seen on https://github.com/backdrop/backdrop/releases. The 1.11.5 release was needed because the update to the 1.12.x branch causes a PHP fatal error when the old options_element contributed module is still installed, as documented on issue #3485.

Even though 1.11.5 is a security release that includes the needed fixes, the Backdrop core update module shows an alert saying that a security update is needed on the Backdrop status page and, if configured to do so, sends email notifications saying that a security update is available that should be applied immediately.

Actual behavior

Backdrop core complains of a needed security update when a secure version of Backdrop is installed that is not the highest numbered security release available (e.g. Backdrop 1.11.5 vs 1.12.1).

Expected behavior

Backdrop core should be able to tell that two security releases on two different branches (e.g. 1.11.x and 1.12.x) are equally secure and should not show a warning on the status page or send email notifications from the update module.

Here's another possibility: Each release includes in the XML feed the security release identifier, e.g. CORE-2019-001. Then when checking for security updates, the current version would check all newer releases for the already existing "security" flag, and check that all versions within the same minor release don't have the same security release identifier.

I think we could make an additional entry for <security_identifiers> that contains 1 or more <security_identifier> tags, like this:

<security_identifiers>
  <security_identifier>SA-CORE-2019-001</security_identifier>
  <security_identifier>SA-CORE-2019-002</security_identifier>
</security_identifiers>

There is already a checkbox for "Security Release". If checked, a multi-value text field appears where you enter the SA identifiers. We could use references to the SA nodes, but IMO strings would be simple and do the job.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions