Composer 2.11 bringt eine Wartefrist für neue Pakete: Einstellung, Grenzen, unser Stand

Composer 2.11 hält frisch veröffentlichte Paketversionen für eine einstellbare Zeit zurück, bevor composer update sie installieren darf. Das Projekt Packagist begründet es mit Beobachtungen der letzten Monate: Die meisten bösartigen Versionen auf Packagist.org stammten von Angreifern, die kurz ein legitimes Konto übernommen hatten. Malware-Scanner schlagen laut Packagist oft schon nach Minuten an. Wer eine Stunde wartet, lässt der Erkennung Zeit. Das unabhängige Portal Socket nennt als Vorfälle dieses Jahres die Übernahme von intercom/intercom-php im April und einen Angriff auf Laravel Lang im Mai.

Ein Cooldown (auch Minimum Release Age) ist eine Policy im Paketmanager: Versionen, die jünger als die eingestellte Frist sind, werden bei der Auswahl übersprungen. Das schützt vor dem Zeitfenster zwischen Veröffentlichung eines gekaperten Pakets und seiner Sperrung. Es schützt nicht, wenn die bösartige Version länger als die Frist unentdeckt bleibt, und es verzögert auch legitime Sicherheitsfixes.

So wird er eingestellt

Die Policy steht unter config.policy und ist nach Packagists Beschreibung nicht standardmäßig aktiv. Ein Tag Wartefrist sieht so aus:

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

period nimmt Zeichenketten wie "6 hours" mit den Einheiten second, minute, hour, day oder week oder eine ganze Zahl in Sekunden. Dasselbe geht in der globalen Konfiguration und über die Variable COMPOSER_POLICY_COOLDOWN_PERIOD, etwa in der CI. Ausnahmen für eigene Pakete trägt man unter ignore ein, zum Beispiel "mycompany/*" mit einer Begründung. Die vollständige Syntax steht in der Composer-Dokumentation.

Die Frist greift bei update, require, init und create-project. composer install installiert weiter exakt, was in der composer.lock steht. Ein volles composer update bewertet alle Pakete neu: Liegt in der Lock-Datei eine Version, die noch in der Frist steckt, kann Composer sie durch eine ältere ersetzen.

Der Haken bei Sicherheitsfixes

Mit einem Tag Frist installiert Composer einen Sicherheitsfix in den ersten 24 Stunden nicht von selbst. Automatisch ausnehmen kann es ihn nicht. Packagist erklärt es so: Ein Angreifer mit Zugriff auf das Repository hat die Rechte des Maintainers und kann selbst eine Advisory veröffentlichen oder nach einer echten Advisory eine bösartige Version nachschieben. Jede Regel, die nach Advisory-Daten ausnimmt, wäre eine Umgehung.

Für den Eilfall gibt es composer update --no-cooldown vendor/paket. Der Schalter überspringt nur die Frist. Sperren für Versionen mit Sicherheitshinweisen oder Malware bleiben aktiv. Das setzt voraus, dass jemand die Lücke bemerkt. Packagist rät deshalb zu einer Frist von wenigen Stunden bis zu einem Tag und zu einer Benachrichtigung bei Advisories.

Warum das erst mit 2.11 kommt: Das bisherige Feld time kann der Veröffentlicher selbst setzen, ein Angreifer könnte eine Version also um Wochen zurückdatieren. Packagist.org liefert deshalb seit der Änderung in composer/packagist#1765 ein published-time, das der Dienst beim ersten Bereitstellen selbst setzt. Fehlt es bei einem anderen Repository, bricht Composer mit dem Paketnamen ab, statt die Frist still auszuschalten.

Unser Stand

Wir stehen damit auf der Linie vor dem Cooldown. PHP 8.5.12 im Container gehört zu den behobenen Versionen der Lücken vom 21. Oktober (PHP-Lücken am Patch-Tag), Composer blieb auf 2.10.3. Ob wir auf 2.11 gehen und welche Frist wir wählen, ist offen. Vor einem Test der Policy steht das Composer-Update, denn die Cooldown-Policy gibt es unter 2.10 nicht.

Die Alternative zur Frist im Projekt ist eine zentrale Policy im Repository-Dienst. Private Packagist setzt sie nach eigener Angabe im Packagist-Blog für alle Projekte durch, unabhängig von der Composer-Version der Entwickler.

Weitere Beiträge zu Lieferketten und Updates sammelt der Hub Security und Datenschutz. Wer seine PHP- und Paketstände prüfen lassen will, findet das Angebot unter Leistungen.

Weiterführende Quellen

• Packagist-Blog, Composer 2.11: blog.packagist.com
• Composer-Dokumentation zur Konfiguration: getcomposer.org
• Release 2.11.0 auf GitHub: github.com/composer/composer
• Änderung für published-time: composer/packagist#1765
• Unabhängiger Bericht bei Socket: socket.dev