eystein

I'm involved with Mender which focuses on OTA updates and does not limit the type of update you can deploy, some popular choices: * full system image (with robust a/b layout for rollback support, can also do delta updates to reduce bandwidth with 70-90%) * docker containers * single files or directories * deb packages

You can see the ones OOTB here: https://hub.mender.io/c/update-modules

Also, you can write your own update type if you have a more custom use case: https://docs.mender.io/2.2/devices/update-modules

Does that make sense? Git and buildpack support is not yet OOTB but should be fairly simple to add with a new update module. Note however, that those type of updates may not be easy to roll back (or make atomic - meaning you can get partially installed updates and bricked devices/applications if you lose power).

Hi, I am also working with the Mender project and we have been in touch earlier.

The device support for mender-convert will be drastically widened (actually, there will not be any limit as such) in the Mender 2.3 release, beta ETA in a week or two and final in March. But you can already test it with the development branch today: https://docs.mender.io/development/devices/debian-family

There will also be stock converted images for the most common development boards.

Let us know what you think!

Disclaimer: I work on the Mender project.

Signing and verification in Mender is covered here: https://docs.mender.io/artifacts/signing-and-verification

Signing an archive would probably be good enough for many cases. Block level is a bit simpler (all or nothing) and thus less risk of mixing with unsigned parts (sideloading attacks).

For security-sensitive embedded devices (e.g. payment terminals), block level signatures would allow hardware verification during boot as well (1st stage bootloader verifies 2nd stage, then kernel, etc.) if designed correctly.

Yocto has quite large community and is growing fast. That said, think of Yocto as the first integration not the only - buildroot is surely interesting too but we had to start somewhere. :)

I work on Mender, so I can tell you how automated rollback works there.

The update is written to the inactive rootfs partition, uboot is configured to boot from it and the device is rebooted. Using the bootcount feature of uboot it is possible to roll back automatically if booting fails. Once the mender daemon comes up it will try to report the success of the deployment to the server. If this fails it will also roll back. Only after successfully reporting the success to the server Mender will "commit" the update, meaning configuring uboot to persistently boot from this updated partition.

Mender already does compression, but you are right that there are optimizations that can be made for application updates, e.g. delta or other types of updates. We are planning to implement this as well. The first priority for Mender is to make it robust, i.e. make sure the update is atomic and that you can always roll back.

It is not that uncommon for an updater to support both local and remote updates. For example, Mender has two modes of operation: standalone and managed [0].

Like you, many teams are still doing local updates, or transitioning from local to OTA, at least for some products.

[0] https://docs.mender.io/1.0/Architecture/Overview#modes-of-op...

Thanks! :)

Yes, we have looked into it and the nice thing is that TUF seems to be quite easy to add as an additional security layer down the road.

One interesting challenge is downgrade attacks. How do you allow rollback of a bad deployment while disallowing an attacker to deploy an old and vulnerable version?

Cryptographic signing and verification is in scope for Mender [0], and frankly it should be in scope for all updaters -- too many hacks have happened due to lack of codesigning.

[0] https://tracker.mender.io/projects/MEN/issues/MEN-1020