Contrib.social

Add tests for determining which security releases are considered when a site is on a dev release

Open on Drupal.org →
Created on 15 December 2021, about 3 years ago
Updated 20 April 2024, 10 months ago

Problem/Motivation

working on 📌 Convert update_calculate_project_update_status() into a class Needs work

I realized this logic in update_calculate_project_update_status() is untested:

// If we're running a dev snapshot and have a timestamp, stop
// searching for security updates once we hit an official release
// older than what we've got. Allow 100 seconds of leeway to handle
// differences between the datestamp in the .info.yml file and the
// timestamp of the tarball itself (which are usually off by 1 or 2
// seconds) so that we don't flag that as a new release.
if ($project_data['install_type'] == 'dev') {
if (empty($project_data['datestamp'])) {
// We don't have current timestamp info, so we can't know.
continue;
}
elseif ($release->getDate() && $project_data['datestamp'] + 100 > $release->getDate()) {
// We're newer than this, so we can skip it.
continue;
}
}

If we alway continue if $project_data['install_type'] == 'dev' the test will still pass

$project_data['datestamp'] is set in \Drupal\Core\Utility\ProjectInfo::processInfoList()
it will be the most recent of the values in the core module info files. The problem is that the datestamp value will only be in the info files if Drupal was downloaded via the zip archive not if the project was started via Composer because it is added Drupal packaging. The code above was written before the people started to use composer with Drupal projects. Actually it was written before Composer was released 😱

According to is set in \Drupal\Core\Utility\ProjectInfo::processInfoList() then if no datestamp is in any info file then datestamp will be set to 0. This will mean that if you are on a dev release then no security updates will ever be shown.

If you are using the zip file and are on dev release then security updates may be shown if the security release is greater than(with 100 seconds buffer) the project date.

We should decide if we still want to show security releases when the site is on a dev release and the project was started from a zip file. We don't do this on Composer based projects.

Proposed resolution

if it is set we need a test:
Have a site that is running a dev release.

  1. for a project that has no datestamp, the Composer example, then datestamp will be set to 0 and no security releases should be shown(according to current logic)
  2. For a project where project datestamp is less than the date on a security release then the security release should be shown
  3. For a project where project datestamp is greater than the date on a security release then the security release should NOT be shown

For setting the timestamps see `\Drupal\Tests\update\Functional\UpdateSemverCoreTest::testDatestampMismatch`

for testing 2 and 3 you could use 1 xml fixture with 2 security releases. 1 security release where the release date is greater than datestamp(+100 seconds) and 1 less. only release with the greater date should be shown on the report.

Then for test 1) neither security release should be shown in the case where there is no datestamp set in the test.

Remaining tasks

Decide what the correct behavior is

📌 Task
Status

Fixed

Version

10.3 ✨

Component
Update  →

Last updated 11 days ago

  • Maintained by
  • 🇺🇸United States @tedbow
  • 🇺🇸United States @dww
Created by

🇺🇸United States tedbow Ithaca, NY, USA

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

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024