Contrib.social

Switch failure marker file from *.json to *.yml to prevent it from being readable from the web

Open on Drupal.org →
Created on 16 May 2023, over 1 year ago
Updated 19 May 2023, over 1 year ago

Problem/Motivation

Right now in \Drupal\package_manager\FailureMarker::getPath() we use PACKAGE_MANAGER_FAILURE.json as file name.

This will put the file in the file in the root of the Drupal project. Because .json files are not protected by in the default core .htaccess file or the suggested nginx setup. This means that this file will be readable from the web the project root and the web root are the same.

The relevant piece of Drupal core's .htaccess file:

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl(\.php)?|xtmpl|yml)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config|yarn\.lock|package\.json)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$">

If you are doing this via the form this is probably not a huge deal because a user would be present if the update failed but once we have 📌 Enable unattended updates Fixed we probably don't want this to accessible so bot couldn't scan for it.

Proposed resolution

  1. Change PACKAGE_MANAGER_FAILURE.json to use the yml format. Since the default .htaccess file ensures these are not readable from web.

Remaining tasks

  1. If we really wanted to use .json in core then we could update the default .json but yml may have advantage.
  2. Since it is easy to put comments in .yml files we should make a todo to add comments directly in the file in 🐛 Document what the existence of the PACKAGE_MANAGER_FAILURE.yml means Fixed

User interface changes

None.

API changes

None.

Data model changes

None.

📌 Task
Status

Fixed

Version

3.0

Component

Code

Created by

🇺🇸United States tedbow Ithaca, NY, USA

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024