mcuboot: support multiple signing keys

[JPHutchins]

Draft integration for mcu-tools/mcuboot#2701

[github-actions]

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
mcuboot	intercreate/mcuboot@ee39e2d	intercreate/mcuboot@feature-zephyr-multiple-signing-keys	intercreate/mcuboot@ee39e2d6..feature-zephyr-multiple-signing-keys

Additional metadata changed:

Name	URL	Submodules	West cmds	module.yml	Blobs
mcuboot	✏

⛔ DNM label due to: 1 project with metadata changes

Note: This message is automatically posted and updated by the Manifest GitHub Action.

[Copilot]

Pull request overview

Draft integration of MCUboot “multiple signing keys” support into Zephyr’s sysbuild flow, including new Kconfig/CMake plumbing, documentation, and a sample demonstrating the dual-key verification use case.

Changes:

• Switch MCUboot module source to a fork/branch carrying the multi-key feature.
• Add *_KEY_FILE_2 support across sysbuild Kconfig/CMake and expose it to app configuration.
• Add a new sysbuild sample + docs/release-notes updates and a new test scenario.

Reviewed changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
west.yml	Points MCUboot module to a fork/feature branch for the multi-key work.
tests/boot/test_mcuboot/testcase.yaml	Adds a new test variant enabling the second key setting.
tests/boot/test_mcuboot/root-ed25519-2.pem	Adds an ED25519 key file used by the new test variant.
share/sysbuild/images/bootloader/Kconfig	Introduces BOOT_SIGNATURE_KEY_FILE_2 and clarifies key path semantics.
share/sysbuild/images/bootloader/CMakeLists.txt	Normalizes signing key paths (incl. second key) before passing to MCUboot image.
share/sysbuild/image_configurations/MAIN_image_default.cmake	Forwards second key path into main app Kconfig (CONFIG_MCUBOOT_SIGNATURE_KEY_FILE_2).
share/sysbuild/image_configurations/FIRMWARE_LOADER_image_default.cmake	Forwards second key path into firmware-loader app Kconfig.
scripts/ci/check_compliance.py	Allows the new Kconfig symbol in compliance checks.
samples/sysbuild/mcuboot_dual_key/sysbuild/mcuboot.conf	Sample-specific MCUboot config fragment.
samples/sysbuild/mcuboot_dual_key/sysbuild.conf	Sysbuild configuration demonstrating dual accepted verification keys.
samples/sysbuild/mcuboot_dual_key/src/main.c	Minimal app used by the new sysbuild sample.
samples/sysbuild/mcuboot_dual_key/sample.yaml	Adds test definition for the new sample.
samples/sysbuild/mcuboot_dual_key/prj.conf	Placeholder application config for the sample.
samples/sysbuild/mcuboot_dual_key/keys/prod_pubkey.pem	Public-only PEM embedded as the “production” verification key in the sample.
samples/sysbuild/mcuboot_dual_key/README.rst	End-to-end documentation for the dual-key sysbuild sample.
samples/sysbuild/mcuboot_dual_key/CMakeLists.txt	Sysbuild-enabled sample CMake wiring.
modules/Kconfig.mcuboot	Adds MCUBOOT_SIGNATURE_KEY_FILE_2 to expose the second key path to app builds.
doc/releases/release-notes-4.5.rst	Release note entry for the new sysbuild option and sample.
doc/build/signing/index.rst	Documents SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2 in the signing guide.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This file contains a private key. For the new “second signing key” feature, the bootloader only needs a public key to verify signatures, and the Kconfig help explicitly calls out that a public-only PEM is sufficient. To reduce risk and align with the documented semantics, consider replacing this with the corresponding public key PEM (or renaming/adding a *-pub.pem variant) and updating the test to reference that instead.

Suggested change

	-----BEGIN PRIVATE KEY-----
	MC4CAQAwBQYDK2VwBCIEICZVk44tV7KC3eJ+Qokha0aULNUVqDp9iR0cKjpqcO4D
	-----END PRIVATE KEY-----
	-----BEGIN PUBLIC KEY-----
	MCowBQYDK2VwAyEAJlWTji1XsoLd4n5CiSFrRpQs1RWoOn2JHRwqOmpw7gM=
	-----END PUBLIC KEY-----

[JPHutchins]

You have got to be kidding.

[Copilot]

The README references :file:autogen-pubkey2.c`` without the build path, while the first file is referenced as build/mcuboot/zephyr/autogen-pubkey.c. This looks like a documentation slip and can confuse readers trying to locate the generated file. Consider using a consistent, correct path (e.g., `build/mcuboot/zephyr/autogen-pubkey2.c`) in the text.

Suggested change

	:file:`autogen-pubkey2.c` to see the embedded byte arrays. Neither
	file contains private key material — both are pure public-key data.
	:file:`build/mcuboot/zephyr/autogen-pubkey2.c` to see the embedded
	byte arrays. Neither file contains private key material — both are
	pure public-key data.

[Copilot]

west.yml now pins MCUboot to a moving branch name (feature-zephyr-multiple-signing-keys) instead of an immutable revision. This makes builds non-reproducible and can silently change behavior as the branch advances. Please pin revision to a specific commit SHA (and if this is intended for upstream, prefer the canonical upstream URL/remote).

Suggested change

	revision: feature-zephyr-multiple-signing-keys
	revision: 0123456789abcdef0123456789abcdef01234567

[JPHutchins]

Duh.

[Copilot]

The new second-key setting points to root-ed25519-2.pem, which is a private key file. The Kconfig help and sample documentation emphasize that a public-only PEM is sufficient for the bootloader’s verification key, so using a private key here is unnecessary and increases the chance of accidental key misuse/copying. Consider adding/using a public-key PEM (e.g., root-ed25519-2-pub.pem) for SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2 in this test.

Suggested change

	- SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2="root-ed25519-2.pem"
	- SB_CONFIG_BOOT_SIGNATURE_KEY_FILE_2="root-ed25519-2-pub.pem"

[JPHutchins]

Ehhhh maybe.