Lennart Poettering

Yeah, we'd have to embedd a minimal copy of zlib decompress (or whatever format is en vogue today) in our codebase i fear. yuck.

> We don't need to vendor those, in theory. Providing a path to a static lib during build should be enough so that we can link against it. Well, depends:...

> The EFI_DECOMPRESS_PROTOCOL is provided by the firmware. :P yeah, I'd ignore this bit. sounds risky to rely on that given that such decompressors are parsers and hence security sensitive.

of course, I'd prefer not having to deal with all this. I don't really understand why the decompression code that apparently already exists in the kernel and is regularly used...

@ardbiesheuvel hmm, that's really helpful. The Secureboot signing thing is interesting indeed. If we had the decompression in sd-boot then indeed signing would be easier. In that light it might...

> So what is sd-stub? Is that part of systemd-boot? It's part of systemd, but not of systemd-boot (though it shares some sources with it). It's an UEFI stub, that...

(Marked this as blocker, since structured log messages are API)

I am not convinced. We so far avoided allowlisting individual paths in our unit files, except for files owned by the respective services. I dont think we should start now....

That definitely makes sense to add. Doing some research the iscsi stack supports nameserver= on the kernel cmdline, and the ip= switch also allows DNS config already (the latter which...

sure. resolved should probably allow setting DNS server info, seach domains and /etc/hosts entries, all via credentials. There's an entry in the TODO file for that already.