faern
Add an example
Add an example that updates an OTA enabled app using another app encoded in the flash memory.
Hi Linus
I have a working HTTP OTA update that would make a good example, do you think it would be worthwhile to add it?
Additionally, I have built an extension that performs a checksum of the update using ShA256. I have called this HashedOtaUpdate. Would you be open to a contribution for this?
Thank you for wanting to contribute! I have not read the entire PR yet. I left some comments on some things I think might have been commited by mistake as a first iteration. Will read more of it soon!
Additionally, I have built an extension that performs a checksum of the update using ShA256. I have called this
HashedOtaUpdate. Would you be open to a contribution for this?
Having both signature verification (chip will only trust firmware signed by trusted parties) and integrity verification is something I really want in general. I have not yet coded this up for myself. And I have not decided if it belongs in this crate or outside. If it's put inside the crate then it becomes very opinionated as to what checksum algorithm and/or signature method it uses. But yeah, sha256 is universally a pretty solid choice, so it might be good! As long as we keep it behind an opt-in feature flag and the dependency it pulls in is sane and fairly small.
Additionally, I have built an extension that performs a checksum of the update using ShA256. I have called this HashedOtaUpdate. Would you be open to a contribution for this?
Hmm.. I thought about this again. How is it implemented? I don't want this crate to be locked to a specific format in how the images are transferred to the chip, neither be biased on the transport method.
Having both signature verification (chip will only trust firmware signed by trusted parties) and integrity verification is something I really want in general. I have not yet coded this up for myself. And I have not decided if it belongs in this crate or outside. If it's put inside the crate then it becomes very opinionated as to what checksum algorithm and/or signature method it uses. But yeah, sha256 is universally a pretty solid choice, so it might be good! As long as we keep it behind an opt-in feature flag and the dependency it pulls in is sane and fairly small.
I agree that it is tough to be opionated regarding checksum algorithm. The ESP32 has CRC hardware support built in, for example. I think it would be a good idea to create a trait as the public interface, that we implement for SHA256 as a start, and allow future contributors to extend as desired.
Hmm.. I thought about this again. How is it implemented? I don't want this crate to be locked to a specific format in how the images are transferred to the chip, neither be biased on the transport method.
My implementation is an extension of ota.write, where the incremental checksum is calculated per chunk. This checksum could be any algorithm. Then, I extended ota.finalize(expected_checksum) to confirm the checksum against the expected one.
This is not locked into the specific format or transport method, but does require the user to also transfer the expected checksum over a side channel.