Verify MD5 hashes when downloading release tarballs for the Update manager

Created on 17 November 2010, about 14 years ago
Updated 20 June 2023, over 1 year ago

Over at #605318: Add some garbage collection to the update manager there's been some discussion of verifying MD5 hashes. That's out of scope for #605318 but we should discuss it. hass wrote:

Aside, I guess we should also check the file size or MD5 hash. Sometimes things are rotten and than a file is only downloaded half or with 0kb. In this case a file exists is TRUE, but the TAR could be corrupt. Not sure how we can grab the MD5 generated with every release from d.o... I only say this as I do expect that such issues may also occur (e.g. if d.o goes down while downloading) at least in theory... You never know, anything can happen :-)

As part of #538660: Move update manager upgrade process into new authorize.php file (and make it actually work) we introduced hook_archive_verify() which is invoked after the Update manager downloads something before it tries to install it. So, in theory, there could be a contrib module that does this.

However, we should consider if this needs to be part of core. If so, we certainly don't need to grab the MD5 for all releases on d.o. If it's an update, we already have the release history for the project, which includes the MD5 hashes. If it's a new install, we could just fetch the release history for the one project we're dealing with and find the hash in there.

So, this isn't necessarily a huge or complicated change, there's already a good place for this code to live (update_manager_archive_verify()), and it would almost certainly help with hardening and better recovery in cases of failure (something the Update manager is currently pretty terrible about handling).

📌 Task
Status

Closed: outdated

Version

9.5

Component
Update 

Last updated 3 days ago

  • Maintained by
  • 🇺🇸United States @tedbow
  • 🇺🇸United States @dww
Created by

🇺🇸United States dww

Live updates comments and jobs are added and updated live.
  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇺🇸United States smustgrave

    Wonder with the current state of update manager on D10 if this is still needed?

  • Status changed to Needs review over 1 year ago
  • 🇺🇸United States dww

    Update Manager (as such) is all but deprecated at this point. Package Manager has all of TUF to verify the release artifacts, so this wouldn’t be needed there. I don’t see anyone spending time improving Update Manager anymore, especially since it doesn’t handle composer dependencies which are more and more essential.

    As subsystem maintainer, I’d call this “closed (outdated)”, and start to mark a bunch of other Update Manager (but not Update Status) issues the same or similar.

    However, I think it’d be good to get at least the product managers (if not release managers) to sign off on treating it as if it’s deprecated, even if the replacement isn’t in core (yet).

    Thanks!
    -Derek

  • Status changed to Closed: outdated over 1 year ago
  • 🇺🇸United States smustgrave

    Based on the slack this can be closed out.

Production build 0.71.5 2024