Contrib.social

Create a global "kill switch" for Package Manager

Open on Drupal.org →
Created on 31 March 2022, about 3 years ago
Updated 14 February 2023, about 2 years ago

Problem/Motivation

Allowing updating your codebase in production could be open some potential attack vectors.

Currently the update module in core also has this problem. To mitigate this the Update module allows you to set allow_authorize_operations = FALSE in settings.php which turns off this functionality.

Once Automatic Updates is in core there won't easy way to prevent a user with the correct permissions from turning on the Automatic Updates module and being able to update core, and other projects once we support updating them.

Proposed resolution

Consider adding a global "kill switch" mechanism in Package Manager, a boolean in settings.php like package_manager_disable = FALSE, which if set to TRUE would make all Package Manager operations throw an exception. That's one option;

Or we could just add global kill switch for Automatic Updates and other modules could follow the same pattern if they want to.

Remaining tasks

Decide if we should do this, and how. Then do it. Or don't. :)

User interface changes

TBD

API changes

TBD

Data model changes

TBD, but probably none.

✨ Feature request
Status

Needs review

Version

3.0

Component

Code

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
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.

  • Comment about 2 years ago →
    🇺🇸United States tedbow Ithaca, NY, USA
  • Status changed to Active almost 2 years ago
  • Comment almost 2 years ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Is this still relevant?

    Clarifying current status after ~5 months of silence.

  • Comment 2 months ago →
    🇺🇸United States greggles Denver, Colorado, USA

    I found this issue while looking for a duplicate before creating one.

    I agree with the issue summary.

    Yes, I would say it's important for there to be a way for a site developer, with access to settings.php, to disable the ability to update modules or install new modules from remote locations. It's either very similar to allow_authorize_operations and should be documented/placed in a similar location, or should rely on allow_authorize_operations directly.

    Updating the IS to remove some ambiguity about whether this is a good idea.

  • Comment 2 months ago →
    🇬🇧United Kingdom catch

    Moving this to the core queue, not really a feature.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024