<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 30.4.2022 07:53, Jóhann B. Guðmundsson wrote: </div> <blockquote type="cite" cite="mid:02458409-cf8f-a47b-f2f5-23b762e275f0@gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div class="moz-cite-prefix">On 30.4.2022 05:08, Andrei Borzenkov wrote: </div> <blockquote type="cite" cite="mid:829a0c23-e214-950f-10ea-c801dc4b2f98@gmail.com"> <pre class="moz-quote-pre" wrap="">On 28.04.2022 10:54, Lennart Poettering wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">* systemd-boot is an additional bootloader, rather than replacing an existing one, thus increasing the attack surface. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Hmm, what? "additional bootloader"? Are they suggesting you use grub to start sd-boot? I mean, you certainly could do that, but the only people I know who do that do that to patch around the gatekeeping that the shim people are doing. Technically the boot chain should either be [firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel] (if you buy into the shim thing), and nothing else. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">I guess "additional bootloader" in this context means that distribution cannot use sd-boot as the only bootloader for obvious reason - it is EFI only. So distribution would need to keep currently used bootloader anyway. </pre> </blockquote> Distributions most certainly can become efi only if they chose to do so, there nothing technical that stands in that way. <blockquote type="cite" cite="mid:829a0c23-e214-950f-10ea-c801dc4b2f98@gmail.com"> <pre class="moz-quote-pre" wrap="">If current bootloader already works on platforms supported by distribution, what is gained by adding yet another one? </pre> </blockquote> Freedom of choice If the distribution allows users the freedom to choose from a set of components that the OS "made of" or runs, to fit the user use cases or has targeted use cases ( which bootloaders such as syslinux, u-boot, redboot etc. are aimed at ) then drawing the line at bootloaders makes no sense. If the distribution does not allow users the freedom to choose, then it makes no sense to support multiple variants of components that provide same/similar function in the distribution. </blockquote> On that note if you take the bug report [1] that has been cited in this thread then it's quite evident that Debian is not about the freedom of choice. "We do not consider it valid to have a choice of boot loaders" which immediately excludes ca 20+ Linux/(F)OSS boot loader projects and thus discriminates against the person or group of persons behind those projects and even the person trying to contribute to Debian itself "Hi I'm rescinding this request. I've got a working prototype, but I don't know where this would go." The distribution is not even about freedom of information, which prevents individuals from having the ability to seek and receive and impart information effectively. ( to understand the how and thus the why the conclusion was reached which for in this particular case *all* bootloaders projects could look at the dialog, learn from it and fix anything if it affected them or correct any misunderstanding that might be happening. ) "> Is this discussion public? Can you share it? We unfortunately do not have a written record of it." ... JBG </body> </html>