Support for Image Type Option

To select the appropriate built-in method (update handler) for writing an image to a slot, RAUC matches the image type to the slot type. While the slot type was explicitly configured in the system.conf file, the image type was derived from the filename extension of the image.

Over time, it became apparent that different tools and build systems have different opinions about what “common” filename extensions are. As a result, we received several requests to support matching additional extensions like .bin, .verity, and others. However, adding these all would have made the matching mechanism more and more complex.

[image.rootfs]
filename=bootloader.bin
type=raw

For compatibility, the filename-based image type detection remains supported if no explicit type is set.

The rauc info command now also always displays the image type, indicating if it was detected based on the filename:

Supporting Directories in Bundles (Again)

Starting with v1.12, RAUC stopped modifying the bundle input directory during bundle generation by creating a hard-linked working copy.

This change dropped support for symbolic links and directories as bundle content.

Following feedback from users, customers, and contributors who reached out as mentioned in the FAQ, support for symbolic links was reintroduced in RAUC v1.13 and now v1.15 also brings back support for (non-hidden) directories. Hidden directories remain reserved for use by RAUC.

Installation Date-Based Slot Selection: Support for A/B/C Updates

With RAUC v1.15, the logic for selecting the target slot group has changed in cases where multiple options exist. Previously, RAUC always picked the first inactive slot group. Now, it selects the one with the oldest installation date.

For most A/B setups this makes no difference, but it improves behavior when updating from a recovery system or in configurations with more redundancy, such as an A/B/C layout. It ensures that updates always alternate between the inactive candidates and that RAUC does not overwrite the most recent installation unnecessarily.

Admittedly, although it comes with advantages over pure A/B (where you can more quickly brick the update), an A/B/C setup will be rarely used due to its additional space consumption.

Preparation for Multiple Signer Support

While RAUC currently supports only a single signer per bundle, there are valid use cases for having and verifying against multiple signers. Such setups enable more flexible and secure verification policies, depending on project or certification requirements:

• 1 of M: A bundle is accepted if at least one of several trusted signers has signed it This is useful, for example, during CA rollovers or transitions between key hierarchies.
• N of M: Verification succeeds if a minimum number (N) of different trusted signers have signed the bundle. This is relevant in distributed trust models where no single signer should be sufficient.
• M of M: All configured signers must have signed the bundle. This ensures that every stakeholder (for example, development, QA, and production) explicitly approved the release.

RAUC v1.15 does not yet implement verification for these policies, but during this development phase, the necessary groundwork has been prepared to enable it in future releases.

• A pull request for OpenSSL for extending the OpenSSL API to allow partial verification was created.
• A draft pull request for RAUC to support 1 of M and M of M has been created.

What already made it in this release is

• Refactoring and test infrastructure preparation in RAUC to enable testing multiple signers
• The rauc resign command has been extended with an --append argument, which allows adding new signatures to existing signed bundles.

Other New Features

• A new size-limit configuration option is now supported for the boot-emmc slot type. It is meant to be used in setups where unrelated data stored on the eMMC boot partitions must be preserved and migrating it to a better location is not feasible. RAUC also verifies that the image fits into the defined slot before writing.
• Especially on constrained systems, calculating the block hash index for adaptive updates can take a noticeable amount of time. To avoid the impression of a stalled update, RAUC now provides progress reporting during hash index generation.
• The CLI option -C/--confopt for manually overriding config values, now also works even if no config file is available. This allows using it for host tooling cases like rauc info --confopt=keyring:check-purpose=codesign ...
• Some preparations and improvements for the upcoming built-in polling support made their way into this release, like ETag-based caching or sending custom headers for rauc info/InspectBundle(), too.
• A new allowed-signer-cns configuration option allows to restrict which certificates are accepted when verifying bundle signatures using a list of CommonNames.

For a full list of changes, see the v1.15 changelog.

Thanks!

We’d like to thank all contributors, customers, testers, and users for sharing their valuable feedback, feature contributions, and bug fixes that continuously make RAUC more robust and dependable.