Make WordPress Core

Opened 2 months ago

Last modified 12 days ago

#60611 new enhancement

Bootstrap/Load: Refactor debug.log handling for enhanced protection and usability

Reported by: itschristiandale's profile itschristiandale Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.5
Component: Bootstrap/Load Keywords: has-patch
Focuses: Cc:

Description

This commit addresses concerns related to the /wp-content/debug.log file being publicly accessible, which may contain sensitive information in some circumstances. To mitigate this risk, a randomly generated string is now appended to the debug log filename.

Additionally, the debug logs have been relocated to a dedicated directory for improved organization and convenience. These changes enhance both the protection and usability of the debug.log subsystem.

Change History (4)

This ticket was mentioned in PR #6164 on WordPress/wordpress-develop by @itschristiandale.


2 months ago
#1

  • Keywords has-patch added

This commit addresses concerns related to the /wp-content/debug.log file being publicly accessible, which may contain sensitive information in some circumstances. To mitigate this risk, a randomly generated string is now appended to the debug log filename.

Additionally, the debug logs have been relocated to a dedicated directory for improved organization and convenience. These changes enhance both the protection and usability of the debug.log subsystem.

Trac ticket: https://core.trac.wordpress.org/ticket/60611

@lucasbustamante commented on PR #6164:


12 days ago
#2

Instead of generating a new debug log for every request, maybe we could use a deterministic, unique filename based on that site's salts? If the debug log file is persistent, I think there's no need for the debug directory, we basically keep everything as-is, but just randomize the debug log filename. Also, it could be prefixed with a dot to leverage the "hidden file" convention, as most web servers won't serve hidden files to web clients.

@lucasbustamante commented on PR #6164:


12 days ago
#3

Instead of generating a new debug log for every request, maybe we could use a deterministic, unique filename based on that site's salts? If the debug log file is persistent, I think there's no need for the debug directory, we basically keep everything as-is, but just randomize the debug log filename. Also, it could be prefixed with a dot to leverage the "hidden file" convention, as most web servers won't serve hidden files to web clients.

@lucasbustamante commented on PR #6164:


12 days ago
#4

Instead of generating a new debug log for every request, maybe we could use a deterministic, unique filename based on that site's salts? If the debug log file is persistent, I think there's no need for the debug directory, we basically keep everything as-is, but just randomize the debug log filename. Also, it could be prefixed with a dot to leverage the "hidden file" convention, as most web servers won't serve hidden files to web clients.

Note: See TracTickets for help on using tickets.