This is Revision 8. The focus for this revision is making dry-run as the default.

This is revision-7. This includes updates to efi_is_signed and BootOrder
preservation hardening. The previous diff was revision-6
(D58990?id=186344), which replaced the fail-open uefisign behavior with
a fail-safe. Prior revision-5 (D58990?id=186318), and
revision-4 (D58990?id=186193) were significant updates.

Thank you @markmi_dsl-only.net for the detailed feedback and follow-up. This has been a valuable investigation and helped identify both a firmware-specific edge case and a silent failure path in the implementation.

This is revision-6. This includes an important update for uefisign.
The previous diff was revision-5 (D58990?id=186318), and
revision-4 (D58990?id=186193) was a significant update.

This is revision-5. This includes important updates to revision-4.
The previous diff was revision-4 (D58990?id=186193).

This is revision-4. The previous diff was revision-3 (D58990?id=185468).

This is revision-3. The previous diff was revision-2 (D58990?id=184773).

This is a complete revision-2 resubmission. The previous diff was the initial
submission; everything below is new.

In D58990#1354662, @markmi_dsl-only.net wrote:

Something on a related github page: "MBR (non-GPT) disks Not supported (BIOS-only, legacy)"

Turns out that the "BIOS-only" is false: official 64-bit RPi* releases are U-Boot UEFI based and FreeBSD release builds use MBR for that 64-bit aarch64 support. Various RPi* are MBR only (without the bootcode.bin file on a microsd card, anyway) and the RPi4B related EEPROM ones depend on how recent the EEPROM content is. (Different types of "legacy" than was likely intended.) armv7 is also this way as I remember.

[Note: I can and do use GPT USB media but accept the tradeoffs, such as needing a microsd card to be involved or not using old EEPROM content.]

Not supporting MBR at all may well stay true but, if so, more context may need to be mentioned/reported in that case.

Thank you both for the thorough review!