You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The version number field is not trusted to unambiguously represent the firmware that's running on a device. The vcs_identifier can be used, but isn't guaranteed to be populated. The solution of running a SHA-256 over the .fw file after it has been generated is not desirable since things like signing .fw files would change the computed hash but not alter the contents.
Proposed solution:
Add a virtual meta-uuid field that can be deterministically calculated based on the contents of the .fw file. This could be based on the meta.conf file since that file contains hashes of all of the constituent files. If meta-uuid is calculated rather than stored, it will work on .fw files created with older versions of fwup.
The text was updated successfully, but these errors were encountered:
This is partially supported by v1.2.0. You can see the UUID by dumping the .fw file's metadata using fwup -m. Storage of the firmware UUID on the target can't be automated using only fwup and additions to the fwup.conf, though.
Problem:
The version number field is not trusted to unambiguously represent the firmware that's running on a device. The vcs_identifier can be used, but isn't guaranteed to be populated. The solution of running a SHA-256 over the
.fw
file after it has been generated is not desirable since things like signing .fw files would change the computed hash but not alter the contents.Proposed solution:
Add a virtual
meta-uuid
field that can be deterministically calculated based on the contents of the .fw file. This could be based on themeta.conf
file since that file contains hashes of all of the constituent files. Ifmeta-uuid
is calculated rather than stored, it will work on.fw
files created with older versions offwup
.The text was updated successfully, but these errors were encountered: