-
Notifications
You must be signed in to change notification settings - Fork 61
Fix/ota 3060/check targets before download #1296
Conversation
9ae8adb
to
46a07c2
Compare
@doanac I'm still working on a few things for this PR, but one of the blockers is the aktualizr-lite test. Can you take a look and see if there's an easy solution for you? I don't want to accidentally break your expectations of how it should work. |
46a07c2
to
488dbd3
Compare
Codecov Report
@@ Coverage Diff @@
## master #1296 +/- ##
==========================================
- Coverage 80.03% 79.81% -0.22%
==========================================
Files 177 177
Lines 10392 10475 +83
==========================================
+ Hits 8317 8361 +44
- Misses 2075 2114 +39
Continue to review full report at Codecov.
|
488dbd3
to
ac47217
Compare
@patrickvacek - i've fetched your branch and have re-created the failure. I'm traveling to ELC today, so it might be a couple of days before I get real time to debug. One side comment I'd add to this PR: We could probably add a verifyTarget method to the docker-app-manager code that checks to validate the .dockerapp target is syntactically valid. |
@@ -536,27 +527,33 @@ result::Download SotaUptaneClient::downloadImages(const std::vector<Uptane::Targ | |||
result::Download result; | |||
std::vector<Uptane::Target> downloaded_targets; | |||
|
|||
result::UpdateStatus update_status = checkUpdatesOffline(targets); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@patrickvacek - this looks to be the call that's breaking aktualizr-lite. The problem is that downloadImages was originally a code path that did not have any Uptane dependencies and checkUpdatesOffline
is adding one in.
I haven't fully thought through this, but one way we could avoid the Uptane path is by making the downloadImage
method public so that aktualizr-lite could call that directly and maybe the new pacman->verifyTarget
API as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks to be the call that's breaking aktualizr-lite.
Agreed.
The problem is that downloadImages was originally a code path that did not have any Uptane dependencies and
checkUpdatesOffline
is adding one in.
Yes, it should've always been there, but we were lazy before.
one way we could avoid the Uptane path is by making the
downloadImage
method public so that aktualizr-lite could call that directly
Not my favorite solution, but I'm not sure how many options we have, and I think we've already set the precedent that it's okay for tools in the aktualizr repo to access SotaUptaneClient functions directly, but "normal" users should go through the Aktualizr class API.
maybe the new
pacman->verifyTarget
API as well
That is called automatically during installation. Why would you want to call it after downloading?
We could probably add a verifyTarget method to the docker-app-manager code that checks to validate the .dockerapp target is syntactically valid.
Cool, sounds like a good idea!
I'm traveling to ELC today, so it might be a couple of days before I get real time to debug.
That's okay, I still have some work to do on this PR and it's been slow progress due to competing priorities. Anyway, have fun!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe the new
pacman->verifyTarget
API as wellThat is called automatically during installation. Why would you want to call it after downloading?
Now I understand; it's because you don't call uptaneInstall
directly!
I wish it were possible for you to use the same API but just skip the parts you don't need for your package manager of choice. Is it also possible to mock the DockerApp targets like we do for the fake package manager?
6c8b8b4
to
c77a5e2
Compare
709896b
to
454a558
Compare
This is finally ready for review. |
a9c9da7
to
f68ab08
Compare
/* Target was found, but is larger than expected. */ | ||
kOversized, | ||
/* Target was found, but hash did not match the metadata. */ | ||
kHashMismatch, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking a kInvalid
might be good for this enum as well. eg - a debian package or docker-app target content were invalid.
Here's what I've changed to get things going:
|
@doanac Thanks, that did the trick! Your code looks fine for now. We can refine it later. There are now no blockers on this PR, it just needs review. |
@@ -631,18 +627,20 @@ std::pair<bool, Uptane::Target> SotaUptaneClient::downloadImage(const Uptane::Ta | |||
return {success, target}; | |||
} | |||
|
|||
bool SotaUptaneClient::uptaneIteration() { | |||
bool SotaUptaneClient::uptaneIteration(std::vector<Uptane::Target> *targets, unsigned int *ecus_count) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we allowed the targets
parameter to be null? It could help in niche cases, like tests and should be pretty cheap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
uptaneIteration() is now exclusively used during the check for updates, and it actually fetches the necessary metadata. uptaneOfflineIteration() is now exclusively used during downloading and installing to verify the integrity of the stored metadata. If a user then attempts to install a target that doesn't match the stored metadata, it will be rejected. That stipulation required a lot of reworking of the Uptane tests, because several of them installed fake packages as a shortcut. That no longer works, so I had to expand several of the tests quite a bit. As a result, several of these tests are now rather redundant. We should re-evaluate the test cases in uptane_test and aktualizr_test and determine which are still meaningful and unique. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Specifically, if we already thought we downloaded all the metadata we needed (while checking for updates), we shouldn't be downloading more when re-checking the metadata before downloading or installing updates. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Tested at a low level with the fake package manager and at a slightly higher level with OSTree. Fixes OTA-2191. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
checkTargetFile() just checks that the stored metadata is consistent. We need to go further and actually recheck the hash of the downloaded data. Tested at a low level and high level for the fake package manager. Only tested at a high level for OSTree, and because of the limitations of the mocked sysroot, it's not as thorough as it could be. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Currently only checks OSTree targets, but it's a start. Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
Authored-by: Andy Doan <andy@foundries.io> Signed-off-by: Patrick Vacek <patrickvacek@gmail.com>
db8f08f
to
f22b669
Compare
This is still a work in progress, as there is additional work I'd like to include before merging. Also,test_aktualizr-lite
is failing because of my changes and I'd like to discuss with @doanac how to reach a mutually satisfactory solution.As to the changes, the biggest part is to recheck the Uptane metadata before downloading or installing a target.
uptaneIteration()
is now exclusively used during the check for updates, and it actually fetches the necessary metadata.uptaneOfflineIteration()
is now exclusively used during downloading and installing to verify the integrity of the stored metadata. If a user then attempts to install a target that doesn't match the stored metadata, it will be rejected.That stipulation required a lot of reworking of the Uptane tests, because several of them installed fake packages as a shortcut. That no longer works, so I had to expand several of the tests quite a bit. As a result, several of these tests are now rather redundant. We should re-evaluate the test cases in uptane_test and aktualizr_test and determine which are still meaningful and unique.
The other notable change is to only drop Director targets after a failed installation attempt. Otherwise this prevents being able to split updates into multiple individual calls to the Install API call.
(A unit test is pending.)This still isn't my favorite fix for this problem, but in the short term, it's an improvement. [That was already merged in https://github.com//pull/1301.]