[4.1] securedrop-workstation-grsec package not upgradeable

[eloquence]

On a 4.1 system (based off #784), securedrop-workstation-grsec is reported as upgradeable, but sudo apt update && sudo apt upgrade does not result in any actual changes. This also causes a dom0 test failure (it reports that package updates are available).

Initial analysis, see Kev's comment below for likely root cause

Analysis

I'm noticing a discrepancy in the name of the main version of the package vs. the nightlies version:

https://apt-test.freedom.press/pool/main/s/securedrop-workstation-grsec/securedrop-workstation-grsec_5.15.41-1~bullseye_amd64.deb

https://apt-test.freedom.press/pool/nightlies/s/securedrop-workstation-grsec/securedrop-workstation-grsec_5.15.41-dev-20220623-230321%2Bbullseye_amd64.deb

Note the ~ in the version in main vs. the + in the version in nightlies. I wonder if this, or anything else about the main vs. nightlies use, is causing the problem.

[sssoleileraaa]

I recall that we had to change the versioning scheme to $KERNEL-$REVISION~$PLATFORM when adding a CI job for the bullseye package (see https://github.com/freedomofpress/securedrop-debian-packaging/pull/326/files#diff-eaf0b89d9b82219a2a9f4bc81d8177efa2aee59ce8d931dc3e605438a0386dc7R49-R53), but not sure why it's showing + instead of a ~ for nightlies (assuming nightlies is what you're testing)... You can see that we confirmed at one point that CI built the nightlies package properly: freedomofpress/securedrop-builder#326 (comment).

I'm also not sure how this is relevant yet to the issue of the package being upgradeable... perhaps the new + in the name makes the debian comparison logic think that there's a new package when there's not. I'll need to look into the comparison algormithm, but first would like to understand why the name of the package isn't using the ~ anymore.

Did anyone else dig into this yesterday while I was out?

[zenmonkeykstop]

Maybe a dumb question, but why is this even in nightlies? AIUI, the release cycle of this package does not need to be tied to regular development, as the kernel is only going to be updated occasionally, and so it should only need a bump on a kernel update.

[eloquence]

A couple of factors to consider:

• As of Use bullseye templates on 4.1 and and use apt-test+nightlies repos for dev apt-test+main packages for staging #784, a SecureDrop Workstation provisioned as dev will use the nightlies component of apt-test, while one provisioned as staging will use main.
• As I understand it (please correct me if I am wrong), the new Bullseye template is initially configured to use main and ships with the version of the securedrop-grsec package from main.
• On an environment configured as dev (which switches apt-test back to nightlies), both Michael and I have observed the issue with the package being reported as upgradeable but not actually being upgraded.

This may not in fact be an issue at all relevant to non-test environments, as those would be configured to use prod packages throughout. So it may not be a release blocker, but it would still be good for us to understand why apt behaves this way. dpkg --compare-versions reports the nightly version as newer (tilde or no tilde), but does not upgrade to it. Is that expected behavior because the package originates with a different component (originally was installed from main)? If so, why do we only see it for securedrop-grsec?

Terminal output on a dev environment from various apt commands for reference: https://gist.github.com/eloquence/4289354eb31b1356bc3d954b3a6b5ae6

On a staging environment, which uses main throughout, I do not observe this issue.

[zenmonkeykstop]

OK, this is a dependencies issue. The sdw-grsec package depends on the linux image and header packages, and it looks like the nightly sdw-grsec subs in the nightly versions of those packages too, but they don't exist. To see the difference, run apt show for both versions.

A couple of paths to resolution present themselves immediately:

1. remove the securedrop-workstation-grsec nightlies and inject the non-nightly sdw-grsec package into the nightly channel instead (could just be manual) - this would be simplest but would add a manual update step when the kernel was updated
2. update the build process for sdw-grsec to not sub in the nightly version string for those dependencies, but use the same version string as the prod packages - this would require build process changes, but would also allow for stuff like changes in the sdw-grsec metapackage's postint (if for example, you wanted to update boot parameters without changing the kernel).

In either case I agree that this is not going to be an issue in prod, so long as the linux-image and linux-header package deb versions don't get munged in the prod sdw-grsec package's control file.

[legoktm]

Oops. My preference would be to do #1, we don't gain any value from nightlies for this and as previously discussed, the kernel packages are special enough that we should treat them specially. In this case, no nightlies.

[sssoleileraaa]

I agree that this is not a release blocker. Right now, we're testing the template from yum-test main which points to apt-test main for these packages. It definitely needs to get cleaned up and if I understand what's being proposed in #1, then I think no longer building the grsec package in nightlies is best. After we update the kernel and push it to apt-test main in order to build the template that we want to test on yum-test main, we can manually push what we need to nightlies as well.