GNOME Bugzilla – Bug 744771
Check download size and md5
Last modified: 2018-05-04 12:37:28 UTC
Fetching packages can sometimes fail, resulting in wrong download/size/... Furthermore we should ensure what we download is *really* what we want (i.e. not have people tamper downloads). A simple way forward to fix that would be to store in each tarball-based recipe: * the expected size * the MD5 for small packages (limit to be determined) At the fetch step we could then: * Check if file if present, if not download it * Check if filesize is the expected one, if not remove and retry download once (and then fail if it's really wrong) * Check if the MD5 is the expected one (for those where it's specified)
A little while ago I implemented step #2 for convenience because I realized it was very frustrating to fix a partial download issue, so I pushed this to Cerbero: commit 71001328b968547ce3f5e8d6efa2ec903d0f8549 Author: Nirbheek Chauhan <nirbheek@centricular.com> Date: Mon Oct 3 16:21:20 2016 +0530 cerbero: Try to redownload corrupted tarballs Earlier, when we encountered an incomplete or corrupted tarball, we would error out with a CRC check error (for tarballs) or similar. This error would not fix itself if you build the recipe from scratch because the 'fetch' stage just checks if the file exists, and if it does, assumes that it downloaded successfully. You had to manually remove the file, and then when 'extract' errored out because the file didn't exist, you'd have to select '1' to build the recipe from scratch. This is extremely confusing. Now we just overwrite and try to redownload the file once if it's corrupted or partially downloaded. It's not the best solution, but for that we need at least the filesize and sha256sum (md5 has been broken and is insecure) for each tarball.
Still valid *** This bug has been marked as a duplicate of bug 773491 ***