Tag v1.8.0 spostato, metà utenti del client Go hanno ricevuto il vecchio codice

Lo spostamento del tag v1.8.0 su GitHub ha diviso l’utenza in due: metà ha continuato a scaricare il codice iniziale, l’altra metà ha visto i build fermarsi con “SECURITY ERROR”¹. Tutto è partito da un bug scoperto quaranta minuti dopo il rilascio: il client pubblico Go per la tracking API inviava ogni richiesta con l’header account vuoto. La fix richiedeva due righe. L’ingegnere che aveva pubblicato la release ha cancellato il tag, ha fatto il merge della correzione e ha spinto di nuovo v1.8.0 sul nuovo commit, così da evitare che restasse in circolazione una versione sbagliata¹.

Per due giorni l’issue tracker ha raccolto due tipi di segnalazioni. Un gruppo diceva che v1.8.0 spediva ancora l’header vuoto. L’altro vedeva fallire i build con un mismatch di checksum e il messaggio “SECURITY ERROR”¹.

La spiegazione stava nella catena di distribuzione dei moduli Go. Chi scaricava tramite proxy.golang.org otteneva il primo v1.8.0. Il proxy conserva una copia di ogni versione che serve e, in quei quaranta minuti, aveva già preso quella iniziale. La documentazione del proxy è esplicita: una release errata può restare disponibile dal mirror anche dopo la rimozione all’origine. Per il proxy, v1.8.0 coincideva con ciò che aveva già in cache, e quello ha continuato a servire¹.

Chi scaricava direttamente da GitHub, perché GOPROXY era impostato su direct o perché usava un mirror interno, prendeva invece il nuovo commit. Il comando go confronta ogni modulo con il file go.sum locale e con il database di checksum su sum.golang.org. Quel database aveva registrato l’hash del primo v1.8.0. Un hash diverso con la stessa versione è esattamente ciò che il controllo deve intercettare, quindi il download veniva bloccato con l’errore di sicurezza¹.

Per riunificare il comportamento, il team ha riposizionato il tag sul commit originale. Così entrambe le metà vedevano di nuovo la stessa versione. La correzione è uscita poi come v1.8.1. Nel go.mod di v1.8.1 compare una direttiva retract per v1.8.0: il comando go non seleziona quella versione quando cerca l’ultima disponibile, e go list -m -u la segnala come ritirata a chi la usa ancora¹.

Dall’incidente sono nate tre misure. I tag che corrispondono al pattern v* ora sono protetti da una regola che blocca aggiornamenti e cancellazioni per chiunque, inclusi gli amministratori. La checklist di rilascio chiarisce che una versione problematica si sistema pubblicando la successiva. Il workflow di rilascio verifica che il tag in creazione non sia mai esistito prima¹.

Sergey Shinder chiude con una regola pratica: una versione Go smette di appartenerti nel momento in cui qualcuno la scarica. Spostare un tag cambia il repository, non le copie già diffuse. Nelle filiere che coinvolgono proxy e database di checksum, quel gesto crea divergenze difficili da sanare con lo stesso numero di versione¹.