GitLab di Alpine è tornato: la ricostruzione mostra i limiti del numero di versione
Il runtime Ruby personalizzato non aveva ricevuto una correzione. Ora vanno ripristinati autenticazione e segreti delle pipeline sul servizio ricostruito.
Il servizio GitLab di Alpine Linux è nuovamente accessibile, ma per tornare a contribuire non basta recuperare una password. Il progetto ha ricostruito il server e sostituito le sue chiavi segrete dopo un tentativo di sfruttamento di una vulnerabilità critica. Account e cronologia dei progetti sono rimasti; diversi meccanismi usati da persone e processi automatici per autenticarsi devono essere configurati di nuovo.
Le istruzioni pubblicate il 30 ottobre descrivono il lavoro ancora necessario: nuove password e autenticazione a due fattori, nuovi token personali e reinserimento dei valori delle variabili CI/CD. Un repository può quindi aprirsi correttamente nel browser mentre, dietro le quinte, la procedura di rilascio continua a non funzionare.
L'aggiornamento di GitLab non aveva corretto Ruby
Il dettaglio più istruttivo emerge dal resoconto dell'incidente. CVE-2026-97229 riguardava il motore delle espressioni regolari di Ruby, utilizzato da GitLab nell'elaborazione delle configurazioni CI. I pacchetti ufficiali GitLab includevano le correzioni necessarie a Ruby. Il container personalizzato di Alpine usava invece una compilazione standard del linguaggio: l'aggiornamento di GitLab del 22 ottobre non aveva quindi risolto il problema sottostante.
È un esempio concreto della distanza possibile tra il numero di versione di un'applicazione e il software effettivamente presente nell'installazione. Un pacchetto preparato dal produttore può includere modifiche ai componenti che un'immagine personalizzata deve integrare separatamente. Due server che mostrano la stessa versione di GitLab non contengono necessariamente lo stesso ambiente corretto.
Il servizio ricostruito utilizza ora GitLab 19.3.7 con Ruby 3.3.13. Alpine richiama inoltre l'attenzione sulle vecchie copie del proprio container 19.3.6: l'immagine è stata ricostruita con Ruby corretto il 27 ottobre. Il nome del tag, da solo, non dice quando l'amministratore abbia scaricato la copia locale.
Riattivare l'accesso senza riutilizzare i vecchi segreti
Il ripristino riguarda più livelli. Servono una nuova password e una nuova configurazione a due fattori; i precedenti codici di recupero non funzionano più. Rimane disponibile l'accesso esterno tramite GitHub, GitLab.com o postmarketOS. I token personali utilizzati da script o da Git via HTTPS devono essere ricreati.
Per chi mantiene un progetto, conta la differenza tra una variabile e il suo contenuto. Le variabili CI/CD hanno conservato nomi e impostazioni, ma i valori sono vuoti. Un processo di distribuzione può trovare la variabile attesa e fallire comunque perché al suo interno manca la credenziale. Alpine raccomanda, quando possibile, di usare credenziali nuove e di considerare potenzialmente esposti i vecchi valori.
Webhook, mirror e integrazioni richiedono la stessa attenzione. Il fatto che un collegamento funzioni ancora non dimostra che il suo segreto sia rimasto privato. È il problema operativo già emerso nella risposta di Railway sull'esposizione delle credenziali: ripristinare un servizio e disattivare i vecchi accessi sono due attività distinte.
L'avviso SSH va verificato
La nuova macchina ha anche nuove chiavi host SSH, che permettono al client dello sviluppatore di identificare il server. Sono diverse dalle chiavi personali dei collaboratori, conservate da Alpine. Al primo collegamento può quindi apparire un avviso di cambio della chiave host anche se la propria chiave di accesso è ancora valida.
Prima di accettare la sostituzione bisogna confrontare l'impronta presentata con quelle pubblicate nelle istruzioni di riapertura. Ignorare automaticamente l'avviso eliminerebbe proprio il controllo che aiuta a distinguere una ricostruzione prevista da un server inatteso.
Per i collaboratori, il lavoro immediato consiste nel ripristinare credenziali e integrazioni effettivamente utilizzate. Per chi gestisce un'immagine GitLab personalizzata, la lezione è più precisa: controllare il runtime corretto dentro l'immagine, oltre al numero di versione dell'applicazione. L'aggiornamento raggiunge il componente vulnerabile soltanto quando viene sostituito anche quel componente.
