Augment then Replace current Update Manager URL download based updates with Staged-Composer workflow

Whoops. I never commented here when I linked this issue as one of the points for 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active . What’s the status of this? Is it worth immediately resurrecting for 11.0.0 release? Possibly 10.4.x? Can we in fact convert this manual thing to a composer-based solution without needing all of auto updates workings and stable?

Thanks!
-Derek

It seems 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active is the path forward, not this approach. Closing this one.

Thanks,
-Derek

The point of this issue is to make the Composer based workflow as secure as the previous method using authorize.php. Allowing Drupal to have write access to its own code without a mechanism similar to authorize.php allows an attacker who finds a vulnerability to exploit to nullify every other security measure in Drupal.

Indeed, see #3346707-18: Add Alpha level Experimental Package Manager module → and later. Thanks to my raising this red flag 1.5 years ago, package_manager doesn't assume it has write access to your filesystem. 🎉 It supposedly works in both server configurations (just like this legacy 'update manager' stuff from D7). If httpd doesn't have write access, you're supposed to run a CLI command via crontab as the correct UID. See 📌 Add Drush command to allow running cron updates via console and by a separate user, for defense-in-depth Fixed and 📌 Add Symfony Console command to allow running cron updates via console and by a separate user, for defense-in-depth Fixed for details. So it's no longer entirely within the UI. But anyone who is setting up a Drupal site where the files are owned by a different user than httpd (yay for them/us!) is presumably comfortable enough with the CLI to setup such a server-side cron job.

That said, there's going to be nothing for you to "fix" with this legacy UI. 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active is currently completely moving ~5K lines of code. I have no interest in maintaining it as a broken/abandoned contrib module. That train has left the station. 😅

Hopefully, before the new "update_manager" (the new name for "auto_updates" 🙃) lands in core, there will be an option to completely disable unattended updates. Then it truly will be a drop-in replacement for all this cruft, only it'll be speaking composer (and all your external dependencies) instead of manually downloading drupal.org tarballs.

Restoring status. This is a dead end. Please don't waste your time trying to revive it.

Thanks,
-Derek

You misunderstand this issue. We are trying to enable updates through the UI, not the command, by prompting the user for credentials that Drupal does not store. The plan for how to do this can change, but the issue itself is not going away. No one is asking you to maintain legacy cruft. Remove all the code you want.

Moving to ✨ Prompt for temporary access when file system is not writable Needs work .