Composer 2.11 introduce il cooldown: i pacchetti PHP appena pubblicati restano in attesa prima dell'installazione (aggiornato: 31 ottobre 2026, ore 11:19)

Un attesa prima di installare un pacchetto appena pubblicato può sembrare una seccatura. Per l'ecosistema PHP, invece, potrebbe fare la differenza tra una build pulita e una compromessa. Composer 2.11, il gestore di dipendenze per PHP, introduce una policy di "cooldown": le nuove versioni dei pacchetti vengono trattenute per un periodo configurabile prima che Composer accetti di installarle. Inoltre, nella stessa release arrivano diverse correzioni di sicurezza e una risoluzione delle dipendenze più veloce. In gioco c'è la catena di distribuzione del software PHP, presa di mira sempre più spesso con pacchetti legittimi finiti nelle mani sbagliate.

Il problema: la finestra tra pubblicazione e segnalazione

Il ragionamento parte da un'osservazione di Packagist, il repository principale dei pacchetti Composer. «La maggior parte delle release malevole che abbiamo visto su Packagist.org negli ultimi mesi è stata pubblicata da attaccanti che avevano preso brevemente il controllo di un pacchetto legittimo, ad esempio tramite un account GitHub compromesso», spiega il team del progetto.

Composer 2.10 aveva già introdotto una policy anti-malware che blocca l'installazione delle versioni segnalate come malevole. Il limite è evidente: il blocco scatta solo dopo la segnalazione. Tra la pubblicazione e il momento in cui qualcuno se ne accorge resta sempre una finestra, durante la quale chiunque esegua un composer update rischia di scaricare codice ostile.

Il cooldown, chiamato anche "minimum release age", serve proprio a restringere quella finestra. L'idea era stata discussa a giugno, insieme all'analoga funzione min-release-age di npm. Secondo Packagist, gli scanner automatici possono segnalare i primi problemi nel giro di minuti, quindi anche un'ora di attesa dà alla rilevazione automatica la possibilità di intervenire. Le segnalazioni che richiedono una revisione manuale sono più lente: un cooldown da qualche ora fino a un giorno aumenta le probabilità di intercettarle. Il team resta comunque prudente: «Un periodo di cooldown non può garantire che una release malevola venga segnalata in tempo, ma ogni ora di ritardo aumenta le probabilità».

Come si configura il cooldown

La funzione non è attiva di default: il periodo vale null e, se non lo si imposta, non succede nulla. La chiave da usare in composer.json è config.policy.cooldown.period:

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

Il valore può essere una stringa come "6 hours" o "1 day", con unità second, minute, hour, day o week, oppure un intero espresso in secondi. Le espressioni relative come "tomorrow" vengono rifiutate.

Oltre che nel file del progetto, il periodo si può impostare nella configurazione globale di Composer oppure tramite la variabile d'ambiente COMPOSER_POLICY_COOLDOWN_PERIOD, comoda nelle pipeline di CI.

Un dettaglio tecnico è decisivo. Il conteggio parte dal campo published-time, che Packagist.org imposta quando rende disponibile una versione per la prima volta e sul quale l'autore del pacchetto non ha alcun controllo. Il campo time di composer.json, invece, è deciso dall'autore o ricavato dalla data di un commit Git: chi compromette un repository potrebbe retrodatarlo senza fatica. Basare il cooldown su quel valore avrebbe vanificato la protezione proprio nello scenario per cui è stata pensata.

Cosa fa e cosa non fa

Il cooldown interviene quando Composer risolve le dipendenze, quindi con update e require. Il comando composer install continua a installare esattamente quanto riportato in composer.lock. Anche init e create-project saltano le versioni trattenute, mentre outdated e show --latest mostrano la versione più recente consentita e segnalano quelle ancora in attesa. Le versioni di sviluppo come dev-main e i pacchetti di piattaforma non vengono mai trattenuti.

Un aggiornamento parziale (composer update vendor/package) lascia intatti gli altri pacchetti bloccati, mentre un composer update completo rivaluta tutto.

C'è però un rovescio della medaglia: Composer non può distinguere una correzione di sicurezza legittima da una release malevola, perciò ritarda tutte le nuove versioni. Per le urgenze, ad esempio una falla segnalata da composer audit, si può aggirare il blocco con composer update --no-cooldown vendor/package.

Le altre novità: block-scope e addio al fallback sui sorgenti

Le policy personalizzate ottengono l'impostazione block-scope, con tre valori:

• update (blocca durante update, require e remove; è il default)
• install (solo in installazione)
• all (entrambi)

Finora solo la lista anti-malware integrata poteva bloccare durante install, quindi le liste interne delle aziende agivano soltanto in fase di aggiornamento.

Composer 2.11 elimina anche l'opzione temporanea che permetteva di ripristinare il fallback automatico dagli archivi di distribuzione al checkout dei sorgenti, già disattivato di default con Composer 2.10.0 il 28 maggio 2026. I maintainer hanno citato motivi di sicurezza: cambiare in silenzio la sorgente dell'installazione significa rischiare di ricevere codice diverso dall'artefatto previsto. Il percorso inverso, dal sorgente fallito all'archivio, resta supportato, così come preferred-install e --prefer-source.

La scelta non è indolore. Alcune pipeline Drupal che usano repository privati, con download degli archivi in errore (per esempio un 404 sugli archivi privati di GitHub) ma checkout Git funzionanti, potrebbero rompersi. Nella issue #12889 un progetto basato sul pacchetto privato awmemorial/awm_drupal_profile, distribuito tramite Upsun, ha smesso di funzionare dopo la rimozione: l'uso di --prefer-dist da parte della piattaforma di hosting impediva alla preferenza impostata nel progetto di avere effetto.

Quanto deve durare il cooldown

Securing Laravel suggerisce di partire da un giorno, tenendo d'occhio le correzioni di sicurezza con composer audit. Un'ora protegge già da molte versioni malevole, ma solo se la scansione automatica le individua e le segnala correttamente. Quelle confezionate con più cura richiedono probabilmente qualche ora. All'estremo opposto, una settimana di cooldown significa una settimana senza patch: un rischio diverso, ma pur sempre un rischio.

L'aggiornamento si installa con composer self-update. Chi usa Private Packagist, invece, dispone già dei periodi di cooldown e può imporli su tutti i progetti dell'organizzazione, a prescindere dalla versione di Composer usata da sviluppatori, agenti AI e sistemi di CI. Per tutti gli altri, la protezione si attiva con una sola riga di configurazione.

Fonti: blog.packagist.com, daily.dev, securinglaravel.com