Comment 7 for bug 2045552

Least importantly: it seems you based this off 0.4.0-0ubuntu0.22.04.1 in jammy release rather than 0.4.0-0ubuntu0.22.04.2 in jammy-security, so it's missing that changelog entry. 0.4.0-0ubuntu0.22.04.2 was just a no-change rebuild against Go 1.18 though, so it doesn't matter much.

> The kicker is, that there is no measurements specific code in nullboot, as all of it comes from snapd/secboot libraries. Thus these got updated to the exact same revisions as are used by the stable release of snapd (at the time the update was prepared and tested in Noble with Azure).

This makes it seem like there could be a different SRU, vendoring versions of those libraries that *just* have the new measurement code, that would be drastically smaller. Has it been considered? If it's unreasonable effort that's OK, but it'd be much easier to review and more clearly SRU-policy-compliant if it included a minimal diff.

It's not entirely clear to me what the scope of possible failures is here - failure to boot is pleasantly obvious. Is this influenced by user configuration, or does it booting *anywhere* mean it will boot *everywhere*? My understanding of the TPM stack is limited, but my understanding is that if it boots *at all* then it must have booted an expected image - is this correct, or should we also be testing that the update correctly *fails* to boot unexpected images?

And to clarify:
> Double check bios_measurements_log to ensure that the newly update shim was used for boot (https://github.com/canonical/tcglog-parser/tree/master/tcglog-dump can be used to extract checksum of the shim binary used at boot and compared to the one shipped in nullboot
You'd be checking the checksum of /usr/lib/nullboot/shim/shimx64.efi.signed (using what checksum function?)