I am using RAUC for a commercial product, and one of the things we need to accomplish is to encrypt our update bundles. I've manually created an encrypted rauc bundle using a LUKS container. Once the container is opened it can be mounted like normal as a squashfs partition and used by RAUC.
This seems generally useful; if this is something you'd like to see in the project I'd be happy to contribute and submit a pull request. I wanted to seek your input before I begin about the proper scope for this, as it could be achieved in many different ways. Here are the two methods I've narrowed in on. * Option 1: Provide an optional "decryption handler" for the user to implement which provides the bundle path and mount point. A user would implement their decrypt and mount steps as needed. If the config file defines this handler, the update process would essentially run the handler instead of r_mount_loop() in bundle.c. This gives a user the most flexibility as they're not locked into any particular encryption method or even bundle format. Bundle creation gets a little more tricky as there isn't a concept of handlers built in. Could have an optional argument which provides a mounted and empty bundle. * Option 2: Implement encryption support directly into RAUC as a compile option. This could create an encrypted bundle and decrypt and mount during install time. This is much easier to use and allows easy encrypted bundle creation, but is quite a bit less flexible. It also adds a dependency, like cryptsetup, to the project. For either option, there is the possibility of inspecting a bundle file's header and knowing whether to run the default mount function or the handler. This would be useful if you thought clients should be able to accept either encrypted or unencrypted bundles. Perhaps there is a much better way to do this than I've thought of. I'd love to hear your thoughts on this. Best, Evan Edstrom _______________________________________________ RAUC mailing list