secureboot-db: release upgrade from 16.04 to 18.04 modifies changelog.gz but resets mtime

[Oliver O.]

During a release-upgrade from Ubuntu 16.04 to 18.04, the file /usr/share/doc/secureboot-db/changelog.gz is modified, but retains its original mtime. This will interfere with incremental backups, which will fail to pick up the updated file.

The file's first line has changed
from: secureboot-db (1.4~ubuntu0.16.04.1) xenial; urgency=medium
to: secureboot-db (1.4~ubuntu0.18.04.1) bionic; urgency=medium

... but the file time for both file versions is identical:
2018-10-19 20:20:34.000000000 +0200 changelog.gz

[Oliver O. (oliver-o456i)]

Update affected package

[Dimitri John Ledkov (xnox)]

so the mtime is set to the one mentioned inside the changelog, "Fri, 19 Oct 2018 11:20:34 -0700" and that's what's included in the package, and by Debian Policy, one should maintain the timestamps as much as possible.

at the moment we do not provide any guarantees that files in later series, have higher/same/lower mtime than in previous releases. For example, a package in xenial may have an SRU to fix a bug, which doesn't affect and/or has always been fixed in bionic, thus upgrade from xenial to bionic may see files go back in time w.r.t. mtime.

A backup system that exclusively relies on mtime, or mtime increasing linearly, will be broken across release-upgrades. After a release-upgrade a contents/checksum check should be executed to detect changes.

Which backup system are you using?

[Oliver O. (oliver-o456i)]

Thanks for explaining. I am using an internally developed, Python-based backup system. It makes backups from Btrfs snapshots and regularly verifies the integrity of the entire restore process. The verification shows discrepancies such as the one above.

As most backup systems rely on mtime to detect changes for performance, I suppose this is really a widespread problem. It probably goes undetected in the majority of cases as backup systems usually don't do 100% integrity verification lacking file system snapshots.

My backup system uses regexp-based filtering to switch from mtime to content change detection. In this case the relevant line in its YAML configuration file is:

      - { pattern: '^usr/share/doc/[^/]*/changelog[^/]*$', filter: compare-contents }

The problem is not just limited to package installation files as this excerpt shows:

      - { pattern: '^var/lib/sudo/', filter: compare-contents }
      - { pattern: '^var/lib/machines$', filter: compare-contents }
      - { pattern: '^var/cache/man/(.*/)?index\.db$', filter: compare-contents }

And there are even more entries in my list. I wonder whether tinkering with mtime is really such a good idea...