1.16.1 denoted as a regular update instead of a security update

[klonos]

I just double-checked both 1.16.1 and 1.15.3 on b.org, and both release nodes are already marked as security releases:

[indigoxela]

Does anyone know, what the reason is? Is it a server-side thing on b.org or packaging?

[klonos]

@serundeputy and I suspect that it's on the b.org side.

[indigoxela]

Hm... I don't have much insight in how this all works, but Backdrop installs get their info via xml files (correct me if I'm wrong).

The xml file for this release shows security_update true.

[klonos]

Hmm indeed 🤔 ...I tested things quickly on my local and it turned out that dpm($available['project_status']); returns published instead of insecure for some reason 🤷

[indigoxela]

Sometimes I understand things better when reading the Simpletests (yes, I'm a freak 😉).

Strange, the xml structure of those files is different:
<term><name>Release type</name><value>Security update</value></term>

https://github.com/backdrop/backdrop/blob/557824453eeec969800c2ff47db7bde4da036467/core/modules/update/tests/update_test/update_test_basetheme.1_1-sec.xml#L29

It seems, this is missing in current xml files, as the xml provided by updates.backdropcms.org doesn't even contain <terms> tags. And these would get evaluated, if I get the code right...

https://github.com/backdrop/backdrop/blob/557824453eeec969800c2ff47db7bde4da036467/core/modules/update/update.compare.inc#L706

The question is now: how is this supposed to be?

[quicksketch]

So looks like the XML files in the tests are correct, that update.module currently expects <term><name>Release type</name><value>Security update</value></term> in order to report a security update.

We recently updated project module to 1.1.0 on backdropcms.org, I think that's the problem. We previously had this bit of code in project.module 1.0.0:

      // Backwards-compatibility: Provide security update information as a
      // "term". Update.module cares *only* about security updates, it has no
      // support for the "New features" or "Bug fixes" terms.
      if (!empty($security_update)) {
        $output .= "  <terms>\n";
        $output .= "    <term><name>Release type</name><value>Security update</value></term>\n";
        $output .= "  </terms>\n";
      }

That is no longer present. We can restore this in backdropcms.org's XML and it should fix the update notifications. I'll look into where/how we can fix this.

[quicksketch]

Rather than re-introduce this backwards-compatibility into project module, I put it in our custom borg_project.module in backdrop-ops/backdropcms.org@2d6476b

It looks as though this has now fixed the feeds so that the XML expected by Update module is now present again, and updates are showing as security releases again:

[indigoxela]

the XML expected by Update module is now present again, and updates are showing as security releases again

Confirmed in an outdated install. Security updates get themed as security updates again since the terms tag is present in xml:

<terms>
  <term><name>Release type</name>
  <value>Security update</value></term>
</terms>

Should the update module actually evaluate the tag <security_update>true</security_update> instead?

[klonos]

Should the update module actually evaluate the tag <security_update>true</security_update> instead?

That was my thought exactly when I read this comment in the PR:

update module still checks for a taxonomy term (legacy from drupal.org).

Shouldn't we then fix Update module to account for both cases?