Conversation
📝 WalkthroughOverviewThis PR permits usage of Symfony Process v8 by broadening the version constraint in Changescomposer.json: Updated the AssessmentThis is a low-risk, minimal change that requires minimal review effort. The constraint update is additive only—it expands compatibility rather than introducing constraints. Since Symfony Process v8 has no breaking changes relative to v7.3.4, this update is safe. No code changes are required to support the new major version. WalkthroughThis PR expands the Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the symfony/process dependency in composer.json to include support for version 8.0. The reviewer noted that the specific version constraint ^7.3.4 is too restrictive as it targets a version not yet available in the stable channel, and suggested using ^7.0|^8.0 to ensure better compatibility with existing installations.
| "illuminate/support": "^11.0|^12.0", | ||
| "ratchet/pawl": "^0.4.1", | ||
| "symfony/process": "^7.3.4", | ||
| "symfony/process": "^7.3.4|^8.0", |
There was a problem hiding this comment.
The version constraint ^7.3.4 targets a version that is not yet available in the stable channel (current Symfony 7 stable releases are 7.1.x). This prevents the package from being installed in environments using current stable Symfony 7 releases. Unless a specific feature from a future 7.3.4 release is required, it is recommended to use a more inclusive constraint like ^7.0 to ensure compatibility with existing installations. Additionally, while the project uses the | operator, note that || is the preferred syntax for OR constraints in Composer.
| "symfony/process": "^7.3.4|^8.0", | |
| "symfony/process": "^7.0|^8.0", |
There was a problem hiding this comment.
Pull request overview
This PR expands the supported version constraint for symfony/process to include Symfony 8, allowing consumers of this library to use newer Symfony Process releases without requiring a separate dependency override.
Changes:
- Update
composer.jsonto allowsymfony/process^8.0in addition to^7.3.4.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@composer.json`:
- Line 32: The composer.json constraint for "symfony/process" currently allows
vulnerable and breaking v8 releases; update the package constraint to exclude
8.0.0–8.0.4 (e.g., change "symfony/process": "^7.3.4 || ^8.0.5" or ">=7.3.4
<9.0, !=8.0.0, !=8.0.1, !=8.0.2, !=8.0.3, !=8.0.4") and then audit code for
removed/changed APIs (search for Process::setCommandLine,
Process::inheritEnvironmentVariables and places that instantiate Process with a
string — replace with Process::fromShellCommandline or array-based
instantiation) and run CI matrixed against a 7.3.4+ and 8.0.5+ environment to
verify no regressions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| "illuminate/support": "^11.0|^12.0", | ||
| "ratchet/pawl": "^0.4.1", | ||
| "symfony/process": "^7.3.4", | ||
| "symfony/process": "^7.3.4|^8.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Symfony Process version 8.0 breaking changes upgrade guide
💡 Result:
Symfony Process 8.0 breaking changes / upgrade guide What the official Symfony 8.0 upgrade guidance says (context) Symfony’s official UPGRADE-8.0.md states that Symfony 8.0 has the same features as 7.4, but “doesn’t include any deprecated features”, and that the upgrade path is to resolve all deprecation notices first [1]. Process component: concrete breaking/removed APIs you should check for From the Symfony Process component changelog entries, the breaking-style changes you’re most likely to hit during an upgrade are: 1) Command creation: prefer command arrays; use shell wrapper API when you need shell parsing - “Process must be instantiated with a command array, use Process::fromShellCommandline when the command should be parsed by the shell” [2]. - The same changelog notes that the “fromShellCommandline” factory was added specifically “to run commands in a shell wrapper”, and that it parses command-lines using the OS shell (/bin/sh on Unix-like, cmd.exe on Windows) [2][3]. 2) Removed method: Process::setCommandLine - “removed Process::setCommandLine” [2]. 3) Removed method: Process::inheritEnvironmentVariables - “removed Process::inheritEnvironmentVariables()” [2]. 4) Environment variable behavior / API shape changed around env handling - The changelog explicitly says: “environment variables will always be inherited” and that a second array $env = [] argument was added to Process::start, run, mustRun, restart (and to PhpProcess::start) [2]. How to upgrade (checklist) - First, upgrade your Symfony app to 7.4 and eliminate all deprecation warnings; Symfony 8.0 guidance is specifically to resolve deprecations before upgrading [1]. - Then, in your codebase and any custom Process helpers/bundles, search for uses of: - Process::setCommandLine and remove/replace it (it’s removed) [2]. - Process::inheritEnvironmentVariables and remove/replace it (it’s removed) [2]. - For any code that relied on shell parsing of a single command string: - switch to Process::fromShellCommandline($command,...) [2][3]. - For env passing/inheritance logic: - update to the current $env argument patterns and remember the component states that environment variables “will always be inherited” [2]. Sources used (most relevant) - [1] https://github.com/symfony/symfony/blob/8.0/UPGRADE-8.0.md - [2] https://github.com/symfony/process/blob/8.1/CHANGELOG.md - [3] https://github.com/symfony/symfony/blob/8.0/src/Symfony/Component/Process/Process.php - [4] https://symfony.com/doc/current/components/process.html
Citations:
- 1: https://github.com/symfony/symfony/blob/8.0/UPGRADE-8.0.md
- 2: https://github.com/symfony/process/blob/8.1/CHANGELOG.md
- 3: https://github.com/symfony/symfony/blob/8.0/src/Symfony/Component/Process/Process.php
- 4: https://symfony.com/doc/current/components/process.html
🌐 Web query:
Symfony Process version 8 security advisories vulnerabilities
💡 Result:
Symfony Process “version 8” security advisories (as of 2026-05-20) that are relevant to the Symfony Process component are: 1) CVE-2024-51736 / GHSA-qq5c-677p-737q (Windows cmd.exe executable hijack) - What happens: On Windows, if an executable named cmd.exe is located in the current working directory, Symfony\Process may call it when preparing command arguments, enabling possible hijacking. [1] - Affected versions (Symfony Process component): Symfony <5.4.46; >=6,<6.4.14; >=7,<7.1.7. [1] - Fix: The Process class now uses the absolute path to cmd.exe. [1] 2) CVE-2026-24739 (Windows MSYS2 argument escaping / “arbitrary argument injection”) - What happens: When PHP is executed from an MSYS2-based environment (e.g., Git Bash) and Symfony Process spawns native Windows executables, MSYS2’s argument/path conversion can mishandle certain special characters (notably “=”) when Symfony escapes arguments. This can corrupt/truncate arguments, which in turn can lead to unintended filesystem operations (depending on what commands are invoked). [2][3][4] - Version impact relevant to “Process 8”: NVD’s CPE mapping states versions from (including) 8.0.0 up to (excluding) 8.0.5 are affected. [2] - Patch: Upgrade to 8.0.5 (or later) to include the fix. [3][4] Practical next steps (for Symfony Process 8 on Windows) - Ensure symfony/process is upgraded to 8.0.5+ if your Windows workflow uses MSYS2/Git Bash and untrusted input can influence process arguments. [2][3][4] - Also ensure you’re not relying on cmd.exe resolution through the current working directory (the fix is using the absolute cmd.exe path). [1] If you paste your composer.lock entries for symfony/symfony and symfony/process (or your composer constraints), I can map exactly which of the above advisories apply to your specific version set.
Citations:
- 1: https://symfony.com/cve-2024-51736
- 2: https://nvd.nist.gov/vuln/detail/CVE-2026-24739
- 3: https://app.opencve.io/cve/?vendor=symfony
- 4: https://www.sentinelone.com/vulnerability-database/cve-2026-24739/
The claim about no breaking changes is false, and the version constraint permits a vulnerable release.
Symfony Process v8 introduces actual breaking changes: Process::setCommandLine() and Process::inheritEnvironmentVariables() were removed, Process instantiation now requires arrays (use Process::fromShellCommandline() for shell parsing), and environment variable inheritance behavior changed. These will break code relying on the old APIs.
Additionally, the constraint ^8.0 allows versions 8.0.0–8.0.4, all of which are affected by CVE-2026-24739 (Windows MSYS2 argument escaping vulnerability). You need to either:
- Change the constraint to
^8.0.5to exclude vulnerable versions, or - Audit the codebase for uses of the removed methods and old API patterns before supporting v8.
Run CI tests against both 7.3.4+ and 8.0.5+ to catch breaking changes.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@composer.json` at line 32, The composer.json constraint for "symfony/process"
currently allows vulnerable and breaking v8 releases; update the package
constraint to exclude 8.0.0–8.0.4 (e.g., change "symfony/process": "^7.3.4 ||
^8.0.5" or ">=7.3.4 <9.0, !=8.0.0, !=8.0.1, !=8.0.2, !=8.0.3, !=8.0.4") and then
audit code for removed/changed APIs (search for Process::setCommandLine,
Process::inheritEnvironmentVariables and places that instantiate Process with a
string — replace with Process::fromShellCommandline or array-based
instantiation) and run CI matrixed against a 7.3.4+ and 8.0.5+ environment to
verify no regressions.
|
Hey @rennokki , could you please review this and cut a new tag so Symfony users can upgrade please? |
Symfony Process v8 has no breaking changes; we can safely allow it.