This is some notes regarding secure boot quirks and misc issues I encounter.
Microsoft Authenticode apparently relied on crc in ancient iterations. This is important because this implies padding has no effect on checksums, thus the resulting X509 certificate we append to the binaries.
However with cryptographic checksums these do affect the resulting checksum.
This is with Trammells checksum patch:
λ signtest » sbsign --hash-only ./fwupdx64.efi # No certificates 788408ea495d2cd55f6d2d3b5e5d56e130c738917068f9e40b07d69ae79dfd51 λ signtest » sbsign --hash-only ./fwupdx64.efi.signed.gosign # Has certificates 33c1bfe9f9d60822df8c099f88ee841ded43f80471b71a9c2ec65a9a4a2ec132
This is made more explicit with
λ signtest » pesign --hash --nopadding --in ./fwupdx64.efi ./fwupdx64.efi 788408ea495d2cd55f6d2d3b5e5d56e130c738917068f9e40b07d69ae79dfd51 λ signtest » pesign --hash --padding --in ./fwupdx64.efi ./fwupdx64.efi 33c1bfe9f9d60822df8c099f88ee841ded43f80471b71a9c2ec65a9a4a2ec132
This implies that if you where to enroll a SHA256 sum into the
database, the checksum would be different depending if the binary has an
certificate or not. "Yay".
sbverify doesn't need to care about this distinction since it will never
actually have to deal with unsigned executables. Thus it can only care about the
Secure Boot uses two types of signatures. PKCS7 and CMS.
CMS is mandated by Microsoft Authenticode