as directory manifest. The file would be a standard directory listing as
generated by GNU sha256sums.
+* sd-boot: maybe add support for embedding the various auxiliary resources we
+ look for right in the sd-boot binary. i.e. take inspiration from sd-stub
+ logic: allow combining sd-boot via objcopy with kernels to enumerate, .conf
+ files, drivers, keys to enroll and so on. Then, add whatever we find that way
+ to the menu. Usecase: allow building a single PE image you can boot into via
+ UEFI HTTP boot.
+
+* maybe add a new UEFI stub binary "sd-http". It works similar to sd-stub, but
+ all it does is download a file from a http server, and execute it, after
+ optionally checking its hash sum. idea would be: combine this "sd-http" stub
+ binary with some minimal info about an URL + hash sum, plus .osrel data, and
+ drop it into the unified kernel dir in the ESP. And bam you have something
+ that is tiny, feels a lot like a unified kernel, but all it does is chainload
+ the real kernel. benefit: downloading these stubs would be tiny and quick,
+ hence cheap for enumeration.
+
* initialize machine ID from systemd credential picked up from the ESP via
sd-stub, so that machine ID is stable even on systems where unified kernels
are used, and hence kernel cmdline cannot be modified locally