Hi guys
PR #12692 introduces a minimum-release-age config that filters out newly released package versions. The intent is good: a quarantine period is one of the best defenses against supply chain attacks. However the current implementation relies on $package->getReleaseDate(), which is derived from the VCS commit timestamp and/or the time property in composer.json. Both are fully controlled by the package author, making the feature trivially bypassable by any attacker, and more or less pointless in its current form.
As @Seldaek noted in the PR:
An attacker could right now easily fake the release date to put it in the past, as the release is under control of the package authors.
The axios npm supply chain attack showed why this matters: the malicious versions were live for 2-3 hours before detection. A quarantine period would have prevented most installs. An attacker sophisticated enough to compromise a maintainer account is sophisticated enough to backdate git commits.
How other ecosystems solve this
pnpm ships minimumReleaseAge which uses the npm registry's time object, a server-side timestamp set when npm publish is called. The package author can't influence this value (as far as I know). npm itself has adopted the same setting. Yarn recently added npmMinimalAgeGate. All three work because the npm registry owns the publish timestamp.
What's needed
For this feature to provide real supply chain protection, Packagist would need to:
- Record a server-side publish timestamp when a version is first indexed, a date the package author cannot set or modify
- Expose this timestamp in the package metadata API (e.g. as
publish_time)
Composer could then use this registry-controlled timestamp instead of the VCS-derived getReleaseDate().
Without this, a minimum-release-age feature is a speed bump against lazy/automated attacks at best. It doesn't offer any protection against targeted supply chain compromises.
It'd be great if implementing something like this could be prioritised. This is a major security hole for Composer at the moment.
Hi guys
PR #12692 introduces a
minimum-release-ageconfig that filters out newly released package versions. The intent is good: a quarantine period is one of the best defenses against supply chain attacks. However the current implementation relies on$package->getReleaseDate(), which is derived from the VCS commit timestamp and/or thetimeproperty incomposer.json. Both are fully controlled by the package author, making the feature trivially bypassable by any attacker, and more or less pointless in its current form.As @Seldaek noted in the PR:
The axios npm supply chain attack showed why this matters: the malicious versions were live for 2-3 hours before detection. A quarantine period would have prevented most installs. An attacker sophisticated enough to compromise a maintainer account is sophisticated enough to backdate git commits.
How other ecosystems solve this
pnpm ships
minimumReleaseAgewhich uses the npm registry'stimeobject, a server-side timestamp set whennpm publishis called. The package author can't influence this value (as far as I know). npm itself has adopted the same setting. Yarn recently addednpmMinimalAgeGate. All three work because the npm registry owns the publish timestamp.What's needed
For this feature to provide real supply chain protection, Packagist would need to:
publish_time)Composer could then use this registry-controlled timestamp instead of the VCS-derived
getReleaseDate().Without this, a
minimum-release-agefeature is a speed bump against lazy/automated attacks at best. It doesn't offer any protection against targeted supply chain compromises.It'd be great if implementing something like this could be prioritised. This is a major security hole for Composer at the moment.