In Drupal core 11.2, Package Manager has added support for a "direct-write" mode, which allows changes to be made directly on the live site: #3503699: Allow Package Manager to operate directly on the live code base
Individual implementers of Package Manager need to specifically opt into it for it if they want to support it. Automatic Updates implements three different types of sandbox:
This issue is solely to consider the benefits and risks of adding direct-write support to the last two (attended updates).
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
phenaproximaAttended updates only update Drupal core. They always have a human in the loop (that's what makes them "attended"), and they are the equivalent of running the following:
The risk here is that installed contrib extensions could be updated, although
--minimal-changesshould, well, keep that to a minimum. But if there are bad and dangerous constraints in the site's composer.json (e.g., unbounded constraints likedrupal/pathauto:>=1), then this could immediately break a site if done in direct-write mode.One possible mitigation here is for Automatic Updates (or maybe just Package Manager itself) to refuse to even start the update process in direct-write mode if any unbounded constraints are present.
Comment #3
dwwNot to be a broken record, but I hope "direct-write" means "add to the queue for the cron job that runs as the user that owns your files" in the security-in-depth world where httpd does not have direct write access to your codebase, right? 😅
Comment #4
catch@dww I think we need a new issue for that. There is a console command that can do unattended updates (I think) and an issue to document it, but I don't think there's an issue for queuing attended updates. We'd also need an equivalent issue for project browser to add similar functionality there for adding new code too.
Comment #6
phenaproximaThis was discussed with @tedbow, @greggles, @pameeela, @tim.plunkett, and @hestenet at DrupalCon Chicago. We agreed that there is strategic value in allowing sites to update via the UI using direct-write (i.e., no rsync), and since this is in the UI only, it doesn't pose any obvious additional security risk. Ted signed off verbally.
Comment #7
phenaproximaI think this should also be supported for attended contrib updates too.
Comment #8
phenaproximaComment #9
phenaproximaThis is failing tests but I'm going to merge it anyway. The failures are preexisting; I do not think for one second that they're caused by the addition of #[AllowDirectWrite] or by any of the minor PHPStan fixes that I've made here.
The problem is that the build tests are quite messy to begin with; I'd started refactoring them in another issue but got sidetracked. Additionally, we have some validation that interferes with the ability to test against dev branches of core, and that needs to be fixed.
So I'll merge this and try to get everything fixed up in a separate issue before releasing this.
Comment #11
phenaproximaMerged into 4.x.