Where
CMakeLists.txt:24-25 (option(...)), CMakeLists.txt:57-62 (add_compile_definitions(...)), README.md "Security options" table, docs/book/book.md §24.1.
What
Both options are offered with default ON, each is forwarded to the compiler as a definition, and the README presents them as the switches that require Ed25519 signatures and recovery authentication. Nothing reads them:
$ git grep -n "EBLDR_REQUIRE_SIGNATURES\|EBLDR_RECOVERY_AUTH" -- '*.c' '*.h'
(no output)
Measured: configuring the same tree with -DCMAKE_C_FLAGS="-DEBLDR_REQUIRE_SIGNATURES -DEBLDR_RECOVERY_AUTH" and without produces byte-identical output for all 41 non-test object files (cmp over CMakeFiles/**/*.c.o; only the archive timestamps differ). So OFF builds the verifying bootloader too -- fail-closed by accident, but:
- an integrator who reads
CMakeCache.txt concludes that these two flags are what enforce verification; they are not, and a future toggle added "to match the option" would be a way to build a non-verifying bootloader;
- a bring-up script that sets either
OFF gets no signal that the request was ignored;
tests/simulate_tests.py:172-173 "verify" the defaults by checking that the option names appear in CMakeLists.txt, which holds while the switch does nothing (that script is run by no workflow and already fails 9 unrelated checks on master).
docs/book/book.md §24.1 goes further and lists EBLDR_SECURE_BOOT, EBLDR_MULTICORE, EBLDR_RECOVERY and EBLDR_BOOT_MENU as build options. None has ever existed in CMakeLists.txt.
Expected
Signature verification and recovery authentication are unconditional, and the build system and docs should say exactly that: no option that claims to disable them, a configure that refuses OFF instead of silently building the verifying firmware, doc tables that list only options that exist, and a guard so that a forwarded EBLDR_ definition nothing reads cannot come back.
Where
CMakeLists.txt:24-25(option(...)),CMakeLists.txt:57-62(add_compile_definitions(...)),README.md"Security options" table,docs/book/book.md§24.1.What
Both options are offered with default
ON, each is forwarded to the compiler as a definition, and the README presents them as the switches that require Ed25519 signatures and recovery authentication. Nothing reads them:Measured: configuring the same tree with
-DCMAKE_C_FLAGS="-DEBLDR_REQUIRE_SIGNATURES -DEBLDR_RECOVERY_AUTH"and without produces byte-identical output for all 41 non-test object files (cmpoverCMakeFiles/**/*.c.o; only the archive timestamps differ). SoOFFbuilds the verifying bootloader too -- fail-closed by accident, but:CMakeCache.txtconcludes that these two flags are what enforce verification; they are not, and a future toggle added "to match the option" would be a way to build a non-verifying bootloader;OFFgets no signal that the request was ignored;tests/simulate_tests.py:172-173"verify" the defaults by checking that the option names appear inCMakeLists.txt, which holds while the switch does nothing (that script is run by no workflow and already fails 9 unrelated checks on master).docs/book/book.md§24.1 goes further and listsEBLDR_SECURE_BOOT,EBLDR_MULTICORE,EBLDR_RECOVERYandEBLDR_BOOT_MENUas build options. None has ever existed inCMakeLists.txt.Expected
Signature verification and recovery authentication are unconditional, and the build system and docs should say exactly that: no option that claims to disable them, a configure that refuses
OFFinstead of silently building the verifying firmware, doc tables that list only options that exist, and a guard so that a forwardedEBLDR_definition nothing reads cannot come back.