Keep `source-fallback` as an explicit opt-in after 2.11 — private package vendor use case
Maintainer of Backpack for Laravel here. We sell private composer packages and serve them through our own satis instance. I want to offer a real-world case for keeping source-fallback as an explicit opt-in, even though I agree with disabling it by default.
Today this change turned a small mistake of ours into a full outage. Our website hosts our satis repo. A deploy pulled code that referenced a newly-required private package before composer install had run, which took the site down — and with it, the satis endpoint that composer was about to download that same package from. On 2.9 this would have self-healed: dist fails, composer clones the exact locked commit from our GitHub org over SSH, deploy goes green. On 2.10 it printed "Source fallback is disabled", aborted, and left the site down until we rolled back on the server by hand.
I agree the default had to change in https://github.com/composer/composer/pull/12885. A silent dist→source downgrade is a real provenance concern, and most users never knew the fallback existed — they shouldn't get it without asking. You did the right thing there.
But I think removal in 2.11 goes one step too far, for two reasons:
With a lock file, the fallback doesn't change what code gets installed. The lock pins the exact source reference, so a fallback install checks out the same commit the dist zip was built from. For
install(as opposed toupdate), the trust downgrade is much smaller than it first appears.For private-package vendors, dist and source are often the same party. Our dist comes from our satis, our source from our GitHub org, both authenticated against infrastructure we control. Falling back isn't switching to a less-trusted channel — it's a second door into the same house. And availability matters twice for us: when the fallback is gone, every customer CI with a cold cache goes red the moment our satis hiccups.
An explicit source-fallback: true in composer.json is a conscious, auditable decision — visible in the diff, reviewable, greppable. That seems like exactly the right place to land: secure by default, available for those of us who understand the trade-off and need it.
Happy to provide more detail on our setup if it helps.
Source: composer/composer