Notify of outdated kernel/Tor packages in the Journalist Interface

[legoktm]

Description

This is a subtask of #6328.

Currently we monitor SecureDrop versions of known instances, to know that automatic upgrades were successful. Once we start shipping new kernels outside of SecureDrop releases, we will no longer know whether the kernel upgrade was successful (unless if goes super badly and knocks the instance offline >.<).

Despite it being public by implication, we don't want to explicitly expose kernel/tor version numbers publicly (as was proposed in https://github.com/freedomofpress/securedrop/pull/6332). Instead, the idea is to advertise in the Journalist Interface that packages are out of date.

Rather than teach the SD web application how to look at the apt cache, we will have some periodic job (maybe on boot or after unattended upgrades runs) dump a list of packages that haven't been upgraded, and display that. Conceptually it's like a MOTD, but it might make sense to dump the package list as JSON so we have more control over formatting/display in the JI.

[legoktm]

I spent a while looking into the various post-update hooks apt and dpkg provide (https://unix.stackexchange.com/questions/226993/whats-the-difference-between-dpkgpost-invoke-and-dpkgpost-invoke-success has a good explanation) and I don't think there's a great point for us to inject our stuff in. Also if we use a hook we have to write it super defensively to ensure that we don't break apt/dpkg.

So...I think we just have a crontab/systemd timer that dumps the output of apt-get -s upgrade (-s is simulate, so it doesn't actually try to upgrade anything), which looks like:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  base-files bsdutils fdisk libblkid1 libc-bin libc6 libfdisk1 libmount1
  libsmartcols1 libuuid1 mount tar util-linux
13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Inst libc6 [2.31-0ubuntu9.2] (2.31-0ubuntu9.7 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libc6 (2.31-0ubuntu9.7 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst base-files [11ubuntu5.4] (11ubuntu5.5 Ubuntu:20.04/focal-updates [amd64])
Conf base-files (11ubuntu5.5 Ubuntu:20.04/focal-updates [amd64])
Inst bsdutils [1:2.34-0.1ubuntu9.1] (1:2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf bsdutils (1:2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst tar [1.30+dfsg-7ubuntu0.20.04.1] (1.30+dfsg-7ubuntu0.20.04.2 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf tar (1.30+dfsg-7ubuntu0.20.04.2 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libblkid1 [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libblkid1 (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libuuid1 [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libuuid1 (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libfdisk1 [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libmount1 [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libmount1 (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libsmartcols1 [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libsmartcols1 (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst fdisk [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst util-linux [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf util-linux (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst libc-bin [2.31-0ubuntu9.2] (2.31-0ubuntu9.7 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libc-bin (2.31-0ubuntu9.7 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Inst mount [2.34-0.1ubuntu9.1] (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf libfdisk1 (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf fdisk (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])
Conf mount (2.34-0.1ubuntu9.3 Ubuntu:20.04/focal-updates, Ubuntu:20.04/focal-security [amd64])

We'd dump that to a well known file like /opt/pending_updates and the JI would have a regex to parse that file, check if any packages match tor(-geoip)? or linux-kernel... an display a notice for them.

In theory this should only show up if the unattended-upgrades/reboot failed for whatever reason, but the apt-get update part (to get new package listings) worked properly. This would also not catch if the SD instance is booted into an older kernel, but has the new one installed.

[legoktm]

This would also not catch if the SD instance is booted into an older kernel, but has the new one installed.

I take this part back, Python knows the current running kernel via os.uname, so we can special case the version comparison.

[eloquence]

I think it would be worth chatting through the UX for this notification with Tina once she starts next week. There are probably a few important questions to answer:

1. Do we only want to alert on Tor/kernel package update failures, or also others?

2. If we want to cover other cases as well, how would that be disambiguated in the message?

3. Should this show up exclusively in the Journalist Interface view, or do we want to introduce a new "admin alerts" section for this kind of information?

4. Should we show any kind of detail in the message, in an email alert, or elsewhere? Should we link to docs?

5. Is an alert in the UI really the most actionable/effective method to reach admins, or should we use email instead?

We've displayed similar alerts in the JI in the past (especially for the Focal migration), but if we want to make this a more standard part of the system, I think it's worth thinking through how it fits in -- especially in light of a potential future deprecation of the web-based journalist experience and a transition to the workstation.

[legoktm]

• cross-linking #972