Composer 2.11 adds a waiting period for new packages: setting, limits, our status

Composer 2.11 holds back freshly published package versions for a configurable time before composer update may install them. The Packagist project bases this on observations of recent months: most malicious versions on Packagist.org came from attackers who had briefly taken over a legitimate account. According to Packagist, malware scanners often flag a release within minutes. Waiting an hour gives detection time to act. The independent outlet Socket names two incidents this year: the takeover of intercom/intercom-php in April and an attack on Laravel Lang in May.

A cooldown (also called minimum release age) is a package manager policy: versions younger than the configured period are skipped during selection. It covers the window between the publication of a hijacked package and its block. It does not help if the malicious version stays undetected longer than the period, and it also delays legitimate security fixes.

How to set it

The policy lives under config.policy and, as Packagist describes it, is not enabled by default. A one-day period looks like this:

{
  "config": {
    "policy": {
      "cooldown": {
        "period": "1 day"
      }
    }
  }
}

period takes strings such as "6 hours" with the units second, minute, hour, day or week, or an integer number of seconds. The same works in the global configuration and through the variable COMPOSER_POLICY_COOLDOWN_PERIOD, for example in CI. Exemptions for your own packages go under ignore, for example "mycompany/*" with a reason. The full syntax is in the Composer documentation.

The period applies to update, require, init and create-project. composer install still installs exactly what is in composer.lock. A full composer update re-evaluates every package: if the lock file holds a version still inside the period, Composer may replace it with an older one.

The catch with security fixes

With a one-day period Composer will not install a security fix on its own during the first 24 hours. It cannot exempt fixes automatically. Packagist explains why: an attacker with access to the repository has the maintainer's rights and can publish an advisory themselves, or push a malicious version after a real advisory. Any rule that exempts by advisory data would be a bypass.

For urgent cases there is composer update --no-cooldown vendor/package. The flag skips only the period. Blocks for versions with security advisories or malware stay active. This assumes someone notices the vulnerability. Packagist therefore advises a period of a few hours up to a day and notifications for advisories.

Why this only arrives in 2.11: the existing time field can be set by the publisher, so an attacker could backdate a version by weeks. Since the change in composer/packagist#1765, Packagist.org therefore provides a published-time that the service sets itself when it first makes a version available. If another repository lacks it, Composer aborts and names the package instead of silently disabling the period.

Our status

So we are on the line before the cooldown. PHP 8.5.12 in the container is one of the fixed versions for the flaws of 21 October (PHP flaws on patch day); Composer stayed on 2.10.3. Whether we move to 2.11 and which period we pick is open. The Composer update comes before any policy test, because the cooldown policy does not exist under 2.10.

The alternative to a period in the project is a central policy in the repository service. Private Packagist enforces one, by its own account in the Packagist blog, for all projects regardless of the developers' Composer version.

More posts on supply chains and updates are collected in the hub Security and data protection. If you want your PHP and package state reviewed, see Services.

Further reading

• Packagist blog, Composer 2.11: blog.packagist.com
• Composer configuration documentation: getcomposer.org
• Release 2.11.0 on GitHub: github.com/composer/composer
• Change for published-time: composer/packagist#1765
• Independent report at Socket: socket.dev