Filesystem Laravel Package

Product Decisions This Supports

• Emergency Security Patching (new — v5.4.54):

  • The 5.4 LTS branch shipped a [SECURITY] release (v5.4.54) fixing two issues:
    • tempnam() files created with a suffix were not private — temporary files could be readable/writable by other users on the host.
    • Source file mode not preserved on copy — copies could silently change permissions.
  • Decision this drives: whether to schedule an out-of-band dependency bump (vs. waiting for the next sprint/release train). On shared hosting or multi-tenant deployments, this should be treated as patch-now, not backlog.
  • Justification: temp file exposure is an information-disclosure class of bug (backup dumps, media exports, generated reports, cache artifacts) and typically requires no application-code change to remediate — only a Composer constraint bump and redeploy.

• Support-Matrix Correction (affects buy-vs-build and roadmap):

  • The earlier assessment framed this package as PHP 8.4+ only. The 5.4 branch remains actively maintained (still receiving security backports), which means teams on older PHP runtimes can adopt the library — and, critically, must still patch it — without a PHP upgrade project.
  • Decision this drives: stop treating "we're not on PHP 8.4 yet" as a reason to defer filesystem hardening. Two tracks are viable: patch 5.4.x now, migrate to 8.x when the runtime upgrade lands.
  • Caveat to record: v5.4.54 carries the security fixes only. The path-normalization fix from v8.0.9 (backslash handling on UNIX) and newer line items are not confirmed on the 5.4 branch — if cross-platform path bugs are the actual driver, 8.x is still the target, not 5.4.

• Build vs. Buy Decision:

  • Buy/keep this package if:
    • You already depend on it (transitively via Laravel/Symfony) and want a maintained, upstream-patched filesystem layer rather than forked or hand-rolled path logic.
    • You need permission-preserving copies — now available on both the 5.4 and 8.x lines (v5.4.54 / v8.1.0).
  • Build custom logic only if:
    • Your use case is highly specialized (custom filesystem drivers, non-POSIX backends).
    • You have a hard runtime pin below the 5.4 branch's floor and no upgrade path — in which case document the residual temp-file exposure risk explicitly.

• Dependency Hygiene / Supply-Chain Posture:

  • Two releases in quick succession (a functional fix on 8.x, a security fix on 5.4) is a signal the project is actively triaged — a point in favor of relying on it rather than maintaining an internal equivalent.
  • Decision this drives: add filesystem dependency to the security-watch list with an alerting rule on [SECURITY] in release notes, so patches don't rely on someone noticing.

When to Consider This Package

• Adopt (or patch) immediately when:

  • Your composer.lock resolves symfony/filesystem 5.4.x < 5.4.54 — the temp-file privacy issue applies regardless of whether your code passes a suffix; transitive callers may.
  • You run on shared hosting, multi-tenant infrastructure, or any host with untrusted local users — local file disclosure is in scope.
  • You rely on CLI/Artisan filesystem tasks (backups, exports, media processing) that write temporary artifacts before moving them into place.
  • You perform file copies where permissions matter (deployment scripts, config staging, secrets/credential files) and are currently on a version before the mode-preservation fix.
  • Your Laravel app deploys across Windows + Linux and shows path-related bugs — target 8.x for the backslash fix, not 5.4.

• Avoid / deprioritize when:

  • Your use case is simple (single-file reads/writes) and native PHP functions suffice — though the security patch still applies if the package is already in your tree.
  • You're exclusively on Laravel's Storage facade / Flysystem and never touch the Symfony Filesystem class directly — patch the transitive dependency, but don't build a roadmap item around adopting it.
  • You're building greenfield and Flysystem/Spatie already covers your needs — no new adoption justified by this release alone.
  • Your stack explicitly avoids Symfony and adding it increases complexity beyond the value of the fixes.

How to Pitch It (Stakeholders)

For Executives: "A security patch landed in the filesystem library our Laravel app depends on (v5.4.54). It fixes a case where temporary files could be left readable by other users on the same server — relevant if we run on shared or multi-tenant hosting. Remediation is a one-line dependency bump and redeploy: no feature work, no downtime, zero license cost (MIT). Recommend we slot it into the current release cycle as a routine security update, and confirm whether any of our temporary-file workflows (backups, exports, report generation) run on shared infrastructure — that answer determines whether it's a normal patch or a priority patch."

For Engineering Teams: *"What's in v5.4.54 (5.4 LTS branch — [SECURITY] release):

• #65745 — tempnam() files are now created private when a suffix is supplied (previously the suffix path could bypass private creation, leaving temp files with broader permissions).
• #65726 — source file mode is preserved when copying files.

Action:

1. composer show symfony/filesystem — if you're on 5.4.x < 5.4.54, bump to ^5.4.54 and redeploy.
2. Audit tempnam() / temp-file usage: anything writing sensitive payloads (DB dumps, exports, generated documents) to a temp path before an atomic move. Verify umask and resulting file modes rather than assuming.
3. Audit file copies where permissions carry security meaning — config/, .env staging, key material. The mode-preservation fix is a behavior change: copies now keep source modes, so re-test any step that relied on copies landing with default permissions.
4. Test on the deployment target, not just locally — permission semantics differ under containers, Windows, and shared-hosting umask settings.

Version note (important): v5.4.54 is security-only. The path/backslash normalization fix from v8.0.9 is not part of this release. If our driver is cross-platform path correctness, patching 5.4 does not close that gap — the fix path is upgrading to the 8.x line.

Why the package, not a fork: upstream is actively triaged, security fixes are backported to LTS, and the integration is standard Symfony Filesystem — no bespoke abstraction to maintain."*

For Security/Compliance Teams: *"This is a [SECURITY]-tagged release addressing local temp-file exposure:

• Fix: tempnam() now creates files private when a suffix is used — closes a local information-disclosure window for temporary artifacts on shared or multi-tenant hosts.
• Secondary: file mode preservation on copy, improving permission-audit determinism (no silent mode drift during deployment staging).
• Compliance relevance: supports GDPR/ HIPAA expectations around unauthorized local file access and access-control consistency; helps demonstrate timely dependency patching for vulnerability-management controls.
• Recommendation: adopt >= 5.4.54 (or current 8.x) as the minimum approved version; add an alert on [SECURITY] release notes; confirm whether temp-file paths sit on shared storage — if yes, treat as priority remediation and document closure in the patch log."*