The Windows SDK builds libcurl against Schannel, which breaks Composer under ephpm php (and under any consumer that runs Composer with this PHP). Reported downstream as ephpm/ephpm#400; root-caused to the curl SSL backend, not to ePHPm.
Mechanism (verified on Windows against the shipped binary)
curl_version()['ssl_version'] = "Schannel", so curl's MINFO prints SSL Version => Schannel — no /version suffix, unlike OpenSSL's OpenSSL/3.x.- Composer's
Composer\Repository\PlatformRepository parses that line with {^SSL Version => (?<library>[^/]+)/(?<version>.+)$}im. [^/]+ matches \n, so with no slash on the SSL line it overruns into the following MINFO lines until the next /, producing a multi-line synthetic platform package name that ValidatingArrayLoader rejects → composer install/update aborts. --ignore-platform-reqs does not help (invalid name during pool construction).
Confirmed capture: library = "Schannel\nZLib Version => 1.3.2\nlibSSH Version => libssh2".
Why Linux is fine
The Linux lane builds curl against OpenSSL → SSL Version => OpenSSL/x.y.z (slash on the line) → the regex stops at OpenSSL, no overrun. So this is Windows-only; the Linux SDK and anything built on it (the Linux preview host) are unaffected.
Fix options
- Build the Windows curl with OpenSSL instead of Schannel (static-php-cli curl SSL backend). This aligns Windows with the Linux lane and with php.net's official Windows builds, produces
SSL Version => OpenSSL/x, and eliminates the overrun. Tradeoff: OpenSSL needs a CA bundle at runtime, whereas Schannel uses the OS certificate store — so this is a real build-config decision, not a free swap. Worth checking what php.net's Windows builds ship for CA handling and matching it.
- Leave Schannel, document the limitation — Composer is unusable under the Windows embedded PHP until Composer's own regex is fixed. Not great given the org ships Composer packages.
The universal fix is upstream in Composer ([^/]+ → [^/\r\n]+), but that's out of our hands.
Recommendation
Option 1 if the CA-bundle handling is acceptable — it's the alignment that makes Windows behave like Linux and php.net. Not urgent for ePHPm's own preview host (Linux), but it blocks Composer for anyone using the Windows SDK directly.
Refs: ephpm/ephpm#400 (closed, root-caused here).
The Windows SDK builds libcurl against Schannel, which breaks Composer under
ephpm php(and under any consumer that runs Composer with this PHP). Reported downstream as ephpm/ephpm#400; root-caused to the curl SSL backend, not to ePHPm.Mechanism (verified on Windows against the shipped binary)
curl_version()['ssl_version']="Schannel", so curl'sMINFOprintsSSL Version => Schannel— no/versionsuffix, unlike OpenSSL'sOpenSSL/3.x.Composer\Repository\PlatformRepositoryparses that line with{^SSL Version => (?<library>[^/]+)/(?<version>.+)$}im.[^/]+matches\n, so with no slash on the SSL line it overruns into the followingMINFOlines until the next/, producing a multi-line synthetic platform package name thatValidatingArrayLoaderrejects →composer install/updateaborts.--ignore-platform-reqsdoes not help (invalid name during pool construction).Confirmed capture:
library = "Schannel\nZLib Version => 1.3.2\nlibSSH Version => libssh2".Why Linux is fine
The Linux lane builds curl against OpenSSL →
SSL Version => OpenSSL/x.y.z(slash on the line) → the regex stops atOpenSSL, no overrun. So this is Windows-only; the Linux SDK and anything built on it (the Linux preview host) are unaffected.Fix options
SSL Version => OpenSSL/x, and eliminates the overrun. Tradeoff: OpenSSL needs a CA bundle at runtime, whereas Schannel uses the OS certificate store — so this is a real build-config decision, not a free swap. Worth checking what php.net's Windows builds ship for CA handling and matching it.The universal fix is upstream in Composer (
[^/]+→[^/\r\n]+), but that's out of our hands.Recommendation
Option 1 if the CA-bundle handling is acceptable — it's the alignment that makes Windows behave like Linux and php.net. Not urgent for ePHPm's own preview host (Linux), but it blocks Composer for anyone using the Windows SDK directly.
Refs: ephpm/ephpm#400 (closed, root-caused here).