CA-376240: Check signature of driver disks/supp packs during host installation

[GeraldEV]

The GPG key is specified in the updates.xml of the supplemental pack to install.
The key will already be present on the host as keys are installed as part of the main installation before the supp packs are installed.
During test deployments any test/dev keys must be loaded before the supp packs/driver disks are installed.

Tested on XenServer 8

[rosslagerwall]

During test deployments any test/dev keys must be loaded before the supp packs/driver disks are installed.

How would someone do that practically if supp packs are applied during installation?

[freddy77]

It looks like a strong regression. If the support pack is signed on its own when is the key installed in the code? Only the keys from the main repository are installed as far as I can see.

The best thing would be that the installer itself came with the right keys and check everything without having to trust the repositories but at the moment the keys are installed from main repository assuming they are safe.

[GeraldEV]

During test deployments any test/dev keys must be loaded before the supp packs/driver disks are installed.

How would someone do that practically if supp packs are applied during installation?

In my testing, I booted to a shell and then added the key, for an automated test environment the keys would need to be included in the main installation media - this might be impractical for now so we may need an alternative strategy for including the keys

[rosslagerwall]

Maybe a hidden debug option that can be passed on the command-line to revert back to the old behaviour?

[rosslagerwall]

There are some changes from xcp-ng that do something like that:

xcp-ng@afdbe02
xcp-ng@5c56d43

[ydirson]

The best thing would be that the installer itself came with the right keys and check everything without having to trust the repositories but at the moment the keys are installed from main repository assuming they are safe.

What improvement does this give? If the user does not trust the ISO it would result in importing an attacker key on the host, so anyway the user must check the ISO integrity before using it (i.e. manually checking a gpg sig). And then I'd say all imaginable checks are already encompassed by that ISO integrity check.

[ydirson]

There are some changes from xcp-ng that do something like that:

xcp-ng@afdbe02 xcp-ng@5c56d43

Note that for the same reasons as exposed above, I tend to think gpgcheck is make obsolete by repo-gpgcheck, as the repo sig encompasses every single RPM. And that even repo-gpgcheck does not bring any additional security when it comes to the repo in the ISO - which is why the signature checks as we had done them in xcpng-8.2 only impacted the network sources.

At worst, adding security features in the wrong places even give the users a false sense of security, and can lead them to take wrong decisions (ie. not checking the the integrity of the ISO "because there are sig checks already")

[freddy77]

The best thing would be that the installer itself came with the right keys and check everything without having to trust the repositories but at the moment the keys are installed from main repository assuming they are safe.

What improvement does this give? If the user does not trust the ISO it would result in importing an attacker key on the host, so anyway the user must check the ISO integrity before using it (i.e. manually checking a gpg sig). And then I'd say all imaginable checks are already encompassed by that ISO integrity check.

Having the main repository in the same ISO is only an option. If your main repository is on HTTP or FTP and you can check the signature from a key that comes with the installer you can't tamper with unsafe repositories.

[ydirson]

Having the main repository in the same ISO is only an option. If your main repository is on HTTP or FTP and you can check the signature from a key that comes with the installer you can't tamper with unsafe repositories.

Right, and that's what we had added in 8.2.

OTOH, checking sigs when the repo is in the ISO causes issues when the user wants to customize the install media - roughly the same ones as those mentioned above with driver disks signed with a key unknown to the installer.