Aktualizr reports incorrect OSTree hash if it doesn't find the currently-booting version in its targets

[tkfu]

When aktualizr assembles the device manifest, it calls OstreeManager::getCurrent() to assemble the information it needs. That function returns an Uptane::Target, so the current implementation is to try to locate a target matching the currently-running commit hash that aktualizr knows about, return that if we do find one, and return the Uptane::Target::Unknown() target if we don't find anything, which is just a target named "unknown" which reports the hash of an empty string as its hash.

This is incorrect behavior according to the Uptane spec: section 5.4.2.1.2 specifies that the ECU version report MUST contain "The filename, length, and hashes of its currently installed image".

[pattivacek]

Is this happening to you after flashing the device outside of the regular update cycle? If so, then this is a long-running known issue. This is because normally we store some information in the database about installed versions, and if that doesn't happen, libaktualizr gets confused.

IIRC the solution is to reconstruct the necessary data in this case from libostree to populate the manifest (and the database as well, if we still need to keep that). I think a fix was once attempted, but got blocked because ostree admin gives us OSTREE_OSNAME but we really want GARAGE_TARGET_NAME. (There's also OSTREE_BRANCHNAME, which may be redundant with the latter; I don't recall the differences off the top of my head.)

Keep in mind that the length of OSTree updates is always 0, so it's really just the name and hash that we need.

[tkfu]

My view is that the name isn't too important--we could choose to populate it with either of the two options you mention, or just leave it as "unknown". But if we have the hash, there are at least a few things we can do--for example, we can check on the back end if the hash exists in the targets metadata, and display that information. It's also useful for troubleshooting purposes in some cases.

edited to add: The specific use case that I get caught in here is what's reported when the device is first flashed/provisioned. If the image it's provisioned with happens to be in delegated targets metadata, aktualizr won't find it, and using an image from delegated targets metadata is the normal path for our devices/use cases.

[pattivacek]

I agree the hash is most important, but I think the discrepancies with the name were causing some minor problems with the web UI, so that was why it wasn't resolved. Using the hash even without the proper name would still be better than what we're doing now.

[tkfu]

Fixed by #42