UpdateManager#tryUpdate does not check if downloaded update jar is up to date

Question

UpdateManager#tryUpdate does not check if downloaded update jar is up to date

kristofbolyai opened this issue 2 years ago · 6 comments

kristofbolyai commented 2 years ago

File updateFile = getUpdateFile();
            if (updateFile.exists()) {
                future.complete(UpdateResult.UPDATE_PENDING);
                return future;
            }

As seen, there is no check if the update file is the latest one. In fact, there is no check the update files works/is intact. A simple hash check could resolve this, and other problems related to updating, like corrupted update file making the feature not work.

magicus · Answer 1 · 2022-12-14T20:42:47.000Z

Is the hash available from Athena?

kristofbolyai · Answer 2 · 2022-12-14T20:45:23.000Z

Is the hash available from Athena?

Yes, we use it later in the method. And we can easily hash the local file too.

magicus · Answer 3 · 2022-12-14T20:47:51.000Z

It will be trivial to fix after #826 is merged.

It made me realize, though, that I do not verify md5 correctness after download. That is perhaps something that should be added to the NetManager.

kristofbolyai · Answer 4 · 2022-12-14T20:48:50.000Z

that I do not verify md5 correctness after download.

Correctness of what?

magicus · Answer 5 · 2022-12-14T21:05:40.000Z

Of the downloaded file. If we have a hash associated with a file, we check the file in the cache, and if there is a mis-match, we delete the file and download it from the specified url. But since that URL is supposed to render a file with the given md5, we could also use it to verify that the download were successful. I did not think of that use case, only of the md5 as a way to validate the cache.

Then of course comes the question -- what do we do if the md5 is not correct? If we make a mistake in setting the md5 sum, we could get stuck in an eternal loop where we download a file, sees it does not match the supposedly correct md5, ditches it due to the assumption that it must have been a borked download, and tries again, over and over.

kristofbolyai · Answer 6 · 2022-12-14T21:07:04.000Z

Of the downloaded file. If we have a hash associated with a file, we check the file in the cache, and if there is a mis-match, we delete the file and download it from the specified url. But since that URL is supposed to render a file with the given md5, we could also use it to verify that the download were successful. I did not think of that use case, only of the md5 as a way to validate the cache.

Then of course comes the question -- what do we do if the md5 is not correct? If we make a mistake in setting the md5 sum, we could get stuck in an eternal loop where we download a file, sees it does not match the supposedly correct md5, ditches it due to the assumption that it must have been a borked download, and tries again, over and over.

I see. Maybe we don't have to worry about this atm.

Share to