Sarà stata la stanchezza, sarà che quella sera ero semplicemente poco lucido, fatto sta che ho tirato in piedi un tunnel di test con cui giocare e rompere cose in santa pace.
Peccato che poi, volendo sperimentare sul serio, ho dato a DockFlare la conferma per prendere possesso del tunnel principale, quello che tiene in piedi buona parte dei servizi di casa. Quello che non avevo capito è che nell’intervallo di tempo tra il mio clic e l’esecuzione dell’operazione avrei perso tutte le configurazioni, dalla prima all’ultima, nessuna route sopravvissuta, vuoto pneumatico.

Sia chiaro: non è colpa di DockFlare, la conferma l’ho data io e la distrazione era tutta mia. Però intanto ho buttato giù il monitor del Mac, ho imprecato quanto serviva e ho rimandato tutto al giorno dopo. Ricostruire era fattibile, ma significava buttare via un mucchio di tempo. Quando l’ho fatto, ho anche provato a salvarmi la configurazione da qualche parte, un export da poter reimportare velocemente in caso di nuovo disastro, e non ho trovato niente che facesse al caso mio.

Il nome

In quella chat che alimentiamo a pane, cazzate e lamentele ogni giorno si stava parlando di India, di supporto, di call center e di non ricordo neanche più cos’altro. E a me era pure venuta fame senza apparente motivo. È in quel contesto, mentre con l’aiuto di Claude Code mettevo in piedi le prime righe di questo progetto, che ho scelto un nome provvisorio: Tikka Masala. Mi fa sorridere ancora oggi, il provvisorio è diventato definitivo, e il software esiste per rimediare a una mia disattenzione: ne ho avuto bisogno in prima persona e l’ho reso pubblico nella speranza che eviti ad altri la stessa situazione (o per lo meno l’idea è quella di provarci, stile raccomandazione della nonna su cosa devi fare per non prendere freddo).

Cosa fa

Il sottotitolo che ho scelto per il progetto è “backup and restore Cloudflare Tunnels, without the spreadsheet”, e riassume abbastanza bene le intenzioni.

Gli dai un API token di Cloudflare, lui verifica che sia valido, ti elenca i tunnel che vede sull’account e ti permette di salvarne uno snapshot: un file JSON con la configurazione del tunnel così come la restituiscono gli endpoint di configurazione dei Cloudflare Tunnel (regole di ingress, hostname pubblici), più i metadati che servono a ritrovarla (data dell’export, account, ID e nome del tunnel, eventuali note). I metadati e lo storico stanno in un piccolo database SQLite, gli snapshot veri e propri sono file su disco.

Il perimetro è quello e solo quello: la configurazione dei tunnel. Non tocca le impostazioni Cloudflare a livello di account, e non salva – al momento – Access (Applications e Policies), per cui trovi solo delle scorciatoie che ti portano dritto alla sezione giusta della dashboard. Quando serve, gli chiedi di ripristinare: prende lo snapshot e sovrascrive la configurazione remota del tunnel con quella salvata. Puoi rimetterla sul tunnel di origine, su un altro tunnel o su un altro account, e ogni ripristino resta tracciato nello storico (quando, su quale account, su quale tunnel).

I backup li fai partire a mano oppure li lasci a uno scheduler interno (con cron e possibilità di scegliere il fuso orario). Qui la parte che uso di più: per ogni tunnel scegli una frequenza, a ogni esecuzione, una volta a settimana o una volta al mese, e decidi se coprirli tutti o solo un sottoinsieme. Nel mio caso i tunnel che tocco spesso girano a ogni ciclo, quelli fermi da mesi si accontentano del giro mensile. C’è una retention (BACKUP_RETENTION_DAYS, io la tengo a 90 giorni) che dopo ogni nuovo backup fa piazza pulita di quelli più vecchi della soglia, snapshot e relativo storico compresi.

Occhio a una cosa sui permessi del token: per far girare anche i ripristini, Tikka Masala avrà necessità del permesso Cloudflare Tunnel in scrittura (più DNS sulla zona), ma se ti interessa solo il backup puoi tenerlo al guinzaglio e sola lettura. Il token viene cifrato, non resta in chiaro sul disco.

Sotto il cofano è un’applicazione FastAPI in Python, niente di esotico, con un sistema di notifiche via webhook o Telegram per farti sapere quando un backup o un ripristino va storto. L’ho rilasciato pronto per Docker (immagine gfsolone/tikkamasala su Docker Hub o in alternativa ghcr.io/gioxx/tikkamasala via GitHub, con un docker-compose di esempio disponibile sul repository): lo metti in piedi accanto agli altri servizi di casa, lo configuri la prima volta e te ne dimentichi (sempre però rispettando la regola che uno strumento di backup è definibile funzionante solo quando sei in grado di ripristinare senza il minimo errore, quindi provalo prima di metterti comodo sul tuo cuscino).

I numeri, i miei

Lo uso da marzo, senza interruzioni, e nel frattempo siamo arrivati alla versione 1.3.8.
A oggi che scrivo queste righe la mia installazione personale mi restituisce questa situazione:

Unique tunnels     5
Routes archived    5095
Restores           12
Scheduled runs     170
Oldest backup      2026-05-31T03:00:04+00:00
Latest backup      2026-08-29T03:00:04+00:00

Archive retention  90 day(s)
Backups kept       127
Backup storage     1.1 MB
Database size      112.0 KB

Cinque tunnel sotto controllo, 170 cicli di backup programmati, poco più di un mega di spazio occupato per mesi di storico e un database che sta in 112 KB. Il campo dei ripristini segna dodici ma si tratta dei miei test che ogni tanto lancio a tradimento, per fortuna non ho più dovuto usarlo per davvero (anche se i test hanno comunque sovrascritto tunnel di produzione), è il motivo per cui oggi mi fido a lasciarlo lì a lavorare da solo.

Dovrei prevedere anche delle conservazioni più a lungo termine (mensili, annuali), ma è una caratteristica che non è ancora disponibile, mi sono già promesso di tornarci sopra e lavorarci.

In conclusione

È un software piccolo e per certi versi banale, ma per come lavoro io è ormai fondamentale.
Non fa niente di spettacolare: è un’assicurazione contro la tua stessa distrazione.

Trovi tutto su tikkamasala.gioxx.org e sul repo github.com/gioxx/TikkaMasala. Se lo provi, se ci trovi un bug o se hai idee per migliorarlo, le Issue su GitHub sono il canale più rapido per arrivare a me. Per tutto il resto, l’area commenti qui sotto è a tua disposizione, come sempre.

#KeepItSimple

Immagine di copertina: mia, prodotta con l’aiuto dell’intelligenza artificiale che ha lavorato allo sfondo che c’è alle spalle del logo ufficiale di Cloudflare.

Tikka Masala: metti al sicuro i tuoi tunnel Cloudflare è stato scritto da Gioxx per Gioxx.org.

Spoiler: nessun attacco.
Ma per arrivarci mi è servita un’oretta di log, e la spiegazione è abbastanza istruttiva da meritare un post, soprattutto se anche tu tieni attivo, come me, un plugin che avevi installato e dimenticato lì.

La caccia all’intruso che non c’era

Prima cosa, accesso SSH all’hosting e giù dentro i log di Apache.
Cosa cercavo: richieste alla API di YOURLS (yourls-api.php), POST all’area admin/, qualunque cosa somigliasse a una cancellazione pilotata da fuori.

Niente. Zero chiamate alla API in tutto il log. Un solo POST all’admin nella giornata: il mio, fatto dopo aver ricevuto l’allarme per andare a controllare. Il filesystem era pulito: nessuna webshell, nessun file PHP modificato di recente, ~/.ssh/authorized_keys vuoto, nessun utente aggiunto all’array degli amministratori in config.php. Eppure i link sparivano davvero: me lo confermava il database, le righe non c’erano più, le notifiche ricevute dal mio Change Notifier erano la conferma ultima a mezzo posta elettronica (maledettamente comodo, diversamente non me ne sarei accorto per tempo e chissà quanti altri link avrei lasciato per la strada).

Un’azione che tocca il database di YOURLS ma non lascia traccia nei log web è il tipo di contraddizione che di solito significa che stai guardando nel posto sbagliato.

L’indizio era nella mia stessa mail

Come ti dicevo poco sopra, quelle notifiche me le manda un plugin che ho scritto io, YOURLS-ChangeNotifier: invia una mail a ogni creazione, modifica o cancellazione di uno short URL. Dando un’occhiata più approfondita al corpo del messaggio di uno dei messaggi di cancellazione, saltava fuori questo:

Event:   DELETE
When:    2026-08-29T08:26:27+00:00
By:      user: (authenticated)
IP:      34.10.46.191

Due dettagli che prima avevo letto di sfuggita. Il campo By: diceva user: (authenticated) senza nome utente: è l’ultima spiaggia del mio plugin, quello che scrive quando yourls_is_valid_user() dice “sì” ma non riesce a tirare fuori né un login, né un cookie di sessione, né un header di autenticazione. Tradotto: nessun accesso vero all’area riservata.

E l’IP: cambiava a ogni mail. In un caso era quello di un monitor esterno che mi passa a controllare i redirect ogni mattina alla stessa ora.
Non un attaccante: solo chi, per caso, stava visitando quel link nel momento esatto della cancellazione.

Il che restringeva parecchio il campo: qualcosa dentro YOURLS cancellava i link quando venivano visitati.

Il colpevole: un plugin antispam del 2012

user/plugins/antispam/. Il plugin Anti spam di Ozh, uno dei più vecchi dell’ecosistema YOURLS. Attivo da anni sulla mia istanza, mai toccato, completamente uscito dai radar. Fa due cose. Alla creazione di uno short URL controlla la destinazione contro alcune DNS blacklist e rifiuta se è elencata: legittimo. Ma poi c’è la seconda parte, agganciata all’evento redirect_shorturl, cioè eseguita a ogni click:

// Has the remote link become compromised lately? Check on redirection
yourls_add_action( 'redirect_shorturl', 'ozh_yourls_antispam_check_redirect' );
function ozh_yourls_antispam_check_redirect( $url, $keyword = false ) {
    // ...
    if( $chances == mt_rand( 1, $chances ) ) {
        if( ozh_yourls_antispam_is_blacklisted( $url ) != false ) {
            // Delete link & die
            yourls_delete_link_by_keyword( $keyword );
            yourls_die( 'This domain has been blacklisted. This short URL has been deleted from our record.', 'Domain blacklisted', '403' );
        }
    }
}

Con probabilità 1 su 5 (link creato da meno di tre giorni) o 1 su 15, a ogni visita interroga la URL di destinazione contro cinque blacklist:

'zen.spamhaus.org',
'multi.surbl.org',
'bl.spamcop.net',
'combined.abuse.ch',
'dnsbl.sorbs.net',

Se una sola risponde positivo, il link non viene sospeso, non finisce in quarantena, non ti manda un avviso: yourls_delete_link_by_keyword(). Cancellato.
E l’utente si becca un 403, quella pagina da 866 byte che nel frattempo avevo visto passare decine di volte nei log senza dargli peso.

Perché proprio adesso

Perché quelle blacklist, nel 2026, sono in buona parte inaffidabili se non le usi nel modo giusto:

• SORBS (dnsbl.sorbs.net) è stata spenta a giugno 2024. La zona DNS non è garantito che risponda in modo sensato.
• SpamCop e SURBL degradano di proposito le risposte quando le query arrivano da resolver pubblici o ad alto volume, cioè esattamente lo scenario di un hosting condiviso, dove il resolver è in comune con centinaia di altri account.

Il risultato è falsi positivi a raffica. Il readme del plugin, va detto, non nasconde niente:

Checking against DNS blacklists may or may not work for you […] It may even result in all domains being blacklisted from your server. Try and see.

L’ho provato: ha deciso che Reddit, Amazon, un blog tecnico di Microsoft e il mio canale Twitch erano tutti “domini blacklistati”, e li ha rimossi.

Il fix

Disattivazione del plugin: rimosso da active_plugins nel database e cartella rinominata in .antispam.disabled, solo per scrupolo, giuro che poi dopo passo pure a cancellare definitivamente.
Da quel momento nessun link è stato più toccato.

Se anche tu tieni attivo questo plugin, il consiglio è di andare a vedere subito se ti sta erodendo lo storico: cerca i 403 anomali nei log e le eventuali mail di cancellazione. Come protezione antispam ci sono alternative che almeno non distruggono dati: Google Safe Browsing per YOURLS (ma occhio, che pure questo è stato archiviato e non viene più aggiornato da quattro anni), o più banalmente un captcha sull’interfaccia pubblica. Io sto seriamente pensando di mettermi alla ricerca di un sostituto mantenuto ancora oggi o – in alternativa – tirare in piedi qualcosa di nuovo che svolga però questo vecchio mestiere.

Il recupero: le statistiche erano ancora tutte lì

Qui la notizia buona.
Quando YOURLS cancella uno short URL rimuove la riga dalla tabella yourls_url, ma non tocca yourls_log, dove vive lo storico dei click.
Le statistiche c’erano ancora tutte, riga per riga, per ognuno dei link cancellati.

Ho recuperato destinazione, titolo e data di creazione dal dump notturno del database (Server Plan ne tiene uno automatico e non mi costringe così ad andare a recuperare il backup che mi porto in casa con cPanelVault), ho reinserito le righe con un INSERT mirato e ho rimesso i contatori clicks allineandoli al conteggio reale dei record ancora presenti nel log.

Verifica finale con un curl per keyword, per controllare che ogni redirect puntasse di nuovo dove doveva:

/r        301 -> https://www.reddit.com/r/Gioxx/
/shopping 301 -> https://www.amazon.it/shop/gioxx
/ee4li    301 -> https://techcommunity.microsoft.com/.../ba-p/3851357
/twitch   301 -> https://www.twitch.tv/gioxx85

Come se non fosse successo niente, con un’unica eccezione: twitch era stato cancellato prima che partisse il backup della notte, quindi la sua destinazione non era in nessun archivio e ho dovuto ricostruirla a memoria (non che fosse così complicato, ma è giusto dirlo, altrimenti mi sarebbe andato a tirare fuori dall’armadio il backup di qualche giorno fa).

In conclusione

Il giudizio è netto: per come è scritto, cancellazione automatica e irreversibile al primo hit di una qualunque blacklist, per giunta durante il redirect, cioè nel percorso più caldo e meno sorvegliato, questo plugin non ha senso su un’installazione viva e usata nel 2026, e ancora meno su hosting condiviso. Il controllo in fase di creazione è un’altra storia e ci può stare; è l’azione distruttiva a runtime il problema.

Due cose che mi porto a casa.

• La prima: le notifiche via mail su creazione/modifica/cancellazione degli short URL, che tenevo più che altro per curiosità, si sono rivelate l’unico motivo per cui me ne sono accorto in tempo. Se hai un sistema di alert simile, quelle mail vanno lette quando arrivano, non archiviate.
• La seconda: tenere YOURLS aggiornato all’ultima versione (oggi la 1.10.5) resta buona regola a prescindere, il mio YOURLS-diff serve proprio a rendere la cosa meno noiosa, anche se stavolta la versione non c’entrava niente (ma per coincidenza, essendo stata pubblicata una manciata di ore prima rispetto all’accaduto, mi ha fatto sorgere il dubbio di uno 0-day corretto che però mieteva vittime into the wild).

L’area commenti è a tua disposizione, soprattutto se ti è capitato di ritrovarti con dei link spariti e non sapevi da dove partire

#KeepItSimple

Immagine di copertina: Mick Haupt on Unsplash

YOURLS: il plugin antispam che cancellava i miei short URL è stato scritto da Gioxx per Gioxx.org.

Ho quindi fatto qualche ricerca per capire cosa offrisse il mercato del self-hosting, evitando però di tenere in considerazione l’idea e possibilità di ospitare il tutto in casa. Avevo bisogno di qualcosa che si integrasse con il mondo serverless.

Prima scelta: Cusdis (e doccia fredda)

Il primo nome che mi era saltato all’occhio era Cusdis, presentato proprio come “alternativa leggera e privacy-friendly a Disqus”. Sulla carta perfetto: piccolo, self-hostabile, pensato apposta per blog e siti statici.

Poi sono andato a controllare il repository su GitHub, per abitudine, prima di adottare qualsiasi cosa guardo sempre lo stato di manutenzione, e djyde/cusdis risulta archiviato. Un progetto che ha avuto il suo pubblico, ma da metà luglio 2026 non riceve più commit e la repository è chiusa in sola lettura. Nessun annuncio ufficiale che spieghi il perché, semplicemente: fine corsa.

Occhio, non sto dicendo che sia stata una scelta sbagliata a monte, magari l’autore ha semplicemente deciso di chiudere un capitolo, succede. Ma per un progetto pubblico che è sempre esposto su Internet, e che deve restare in piedi per anni e magari ricevere patch di sicurezza, adottare qualcosa di già archiviato il primo giorno sarebbe stato un rischio che non valeva la pena correre.

Waline

Incrociando ulteriori ricerche sono arrivato a Waline, altro sistema di commenti self-hosted, e la differenza si vede subito: repository attiva (commit praticamente ogni giorno), community viva e un set di feature parecchio più ricco rispetto al necessario: supporto Markdown nei commenti, notifiche via email/Telegram/Discord/WeChat e altri canali ancora, pannello di amministrazione integrato, supporto per un bel po’ di database (Postgres, MySQL, SQLite, MongoDB …).

Deploy semplice, tra l’altro: il pacchetto @waline/vercel lo rende pronto per girare come funzione serverless su Vercel, con Neon come Postgres gestito dietro. Repository dedicata (ne ho messa in piedi una sul mio account personale), un index.cjs di poche righe che carica Waline, un vercel.json per i build, e in pochi minuti hai un endpoint di commenti collegato al frontend Docusaurus della KB.

Se vuoi provarlo, ti consiglio di iniziare da qui: waline.js.org/it/guide/get-started.

Le personalizzazioni

Che poi è il classico vaso di pandora rispetto al “set & forget”, quel frangente dello spazio-tempo dove la teoria del “lo metto in piedi in 5 minuti” incontra la pratica di un progetto vero e con alcuni ritocchi sotto al cofano praticamente necessari.

Favicon statiche, per silenziare i log

Prima cosa: ogni browser richiede automaticamente /favicon.ico e /favicon.png quando apre il sito. Waline, non avendoli, li trattava come richieste non gestite e ogni volta finiva un NotFoundError nei log di produzione. Innocuo, ma fastidioso da leggere quando stai cercando altro nei log. Basta aggiungere due file statici e dire a Vercel di servirli direttamente, senza passare dalla funzione Node:

{
  "builds": [
    { "src": "favicon.ico", "use": "@vercel/static" },
    { "src": "favicon.png", "use": "@vercel/static" }
  ],
  "rewrites": [
    { "source": "/((?!favicon\\.ico$|favicon\\.png$).*)", "destination": "index.cjs" }
  ]
}

Le notifiche Telegram (e il template che non ne voleva sapere)

Questa è stata quella più tosta. Volevo essere avvisato su Telegram ogni volta che arriva un commento in attesa di moderazione, così non devo tenere aperta la dashboard tutto il giorno. Waline lo supporta nativamente: bastano tre variabili d’ambiente su Vercel (TG_BOT_TOKEN, TG_CHAT_ID, ed eventualmente un TG_TEMPLATE per personalizzare il messaggio).

Peccato che, appena personalizzato il template, la notifica smettesse di arrivare, e senza errori evidenti. Ci ho girato attorno un bel po’: token giusto (verificato a mano con una chiamata curl diretta all’API di Telegram), chat ID giusto, tutto giusto, eppure niente.
Alla fine, spulciando i log runtime di Vercel riga per riga, è saltato fuori il vero colpevole:

Telegram Notification Failed:{"ok":false,"error_code":400,"description":"Bad Request: can't parse entities: Character '.' is reserved and must be escaped with the preceding '\\'"}

Telegram, quando usi il parse_mode: MarkdownV2, pretende che caratteri come . - _ * [ ] ( ) ~ # + = | { } ! vengano “escapati” ovunque compaiano fuori da un blocco di codice o dalla parte URL di un link. Il mio template ci infilava l’URL del post e il nome del sito in punti non protetti, e ogni dominio ha un punto, ogni tanto un trattino: bastava questo per far cadere l’intero messaggio.

Ho provato a correggere il template più volte, ma affidarsi a un campo di testo multiriga su un pannello web per gestire un fence di codice ``` si è rivelato fragile: a ogni copia/incolla qualcosa andava storto tra a-capo reali e letterali. Alla fine ho spostato tutto nel codice: index.cjs costruisce il messaggio da sé, con una funzione di escaping scritta in JavaScript, e lo invia solo per i commenti con stato “in attesa di moderazione”, esattamente il caso che mi interessava:

function escapeMarkdownV2(text = '') {
  return String(text).replace(/[_*[\]()~`>#+=|{}.!\\-]/g, '\\$&');
}

module.exports = Application({
  plugins: [],
  async postSave(comment) {
    if (comment.status !== 'waiting') return;
    // costruzione messaggio + fetch verso l'API Telegram
  },
});

Per evitare la doppia notifica (quella integrata di Waline più la mia), ho disattivato la prima con DISABLE_AUTHOR_NOTIFY=true, lasciando intatte le email di risposta a chi commenta, che passano da un altro percorso.

Versione bloccata e Dependabot

Ultima rifinitura, più che altro una lezione imparata sul momento: il package.json puntava @waline/vercel sulla versione più aggiornata (latest), comodo perché a ogni deploy scarichi automaticamente l’ultima versione, ma anche un rischio silenzioso, un aggiornamento con un comportamento diverso può arrivare in produzione senza che tu lo sappia. Ho quindi scelto di utilizzare una versione precisa di Waline e ho aggiunto un dependabot.yml che apre una pull request quando viene pubblicata una nuova versione, così l’aggiornamento resta una scelta, non un evento a sorpresa.

In conclusione

La lezione più generale, al di là di Waline in sé: prima di adottare qualcosa, anche uno strumento piccolo come un sistema di commenti, vale sempre la pena guardare lo stato reale del progetto. Un repository archiviato oggi potrebbe risorgere domani con un fork, ma nel dubbio meglio partire da qualcosa di vivo. E il self-hosting, anche via serverless, resta assolutamente sostenibile, basta mettere in conto che i primi giorni si passano più a leggere log che a scrivere codice.

Se vuoi vedere il risultato, la sezione commenti la trovi in fondo a qualsiasi post della KB di Marvellous Codeworks.
Se invece ti va di parlarne o dirmi a che software ti sei affidato tu per gestire commenti su un sito web statico, l’area commenti è a tua disposizione anche qui di seguito, come sempre :-)

#KeepItSimple

Immagine di copertina: Thought Catalog on Unsplash

Waline: un sistema di commenti adatto a Docusaurus è stato scritto da Gioxx per Gioxx.org.

Sia chiaro: so benissimo che è una scelta by-design, la pulizia dei vecchi moduli è a tuo carico, la maggior parte delle volte puoi “ignorarla“. Con Microsoft.Graph il problema è però amplificato dal fatto che non stiamo parlando di un modulo singolo, ma di una quarantina di sub-moduli (Microsoft.Graph.Users, Microsoft.Graph.Groups, Microsoft.Graph.Applications e così via). Se aggiorni e basta, ti ritrovi con due, tre, a volte più versioni della stessa libreria installate in parallelo su C:\Program Files\PowerShell\Modules (o nella tua cartella personale dei PowerShell Modules). Bello per chi ama fare ordine, pessimo per chi deve gestire ambienti di produzione dove ogni versione fantasma è un potenziale problema da capire poi, magari alle 2 di notte durante un incident.

Il problema in pratica

Dopo un aggiornamento mi ritrovo tipicamente così: nuova versione installata, ma la precedente ancora lì, con tutti i suoi sub-moduli:

PS> Update-Module Microsoft.graph -Scope AllUsers
PS> Get-Module Microsoft.Graph* -ListAvailable |
>> Where-Object Version -ne '2.39.0' |
>> Select-Object Name, Version, Path

Name                                             Version Path
----                                             ------- ----
Microsoft.Graph                                 2.38.1  C:\Program Files\PowerShell\Modules\Microsoft.Graph\2.38.1\Mic…
Microsoft.Graph.Applications                    2.38.1  C:\Program Files\PowerShell\Modules\Microsoft.Graph.Applicatio…
Microsoft.Graph.Authentication                  2.38.1  C:\Program Files\PowerShell\Modules\Microsoft.Graph.Authentica…
[...]

Quaranta righe, tutte con la stessa versione vecchia (2.38.1 nel caso oggi analizzato e buttato qui sul blog), tutte da rimuovere. A mano sarebbe una tortura, e infatti un Uninstall-Module Microsoft.Graph -RequiredVersion 2.38.1 da solo non basta: quel cmdlet toglie solo il modulo “ombrello“, non i sub-moduli che dipendono da lui.

La pulizia (quella vera)

La strada che mi ha portato a un risultato pulito è stata questa: prendo tutti i moduli della versione da buttare, li ordino mettendo per ultimo Microsoft.Graph.Authentication (da cui dipendono tutti gli altri, quindi va tolto per ultimo) e per primo Microsoft.Graph (l’ombrello, va tolto per primo):

$targetVersion = '2.38.1'

$oldGraph = Get-Module -Name 'Microsoft.Graph*' -ListAvailable |
    Where-Object Version -eq ([version]$targetVersion) |
    Sort-Object Name -Unique

$uninstallOrder = @(
    $oldGraph | Where-Object Name -eq 'Microsoft.Graph'

    $oldGraph | Where-Object {
        $_.Name -notin @(
            'Microsoft.Graph',
            'Microsoft.Graph.Authentication'
        )
    }

    $oldGraph | Where-Object Name -eq 'Microsoft.Graph.Authentication'
)

foreach ($module in $uninstallOrder) {
    Write-Host "Removing $($module.Name) $targetVersion ..."

    Uninstall-Module `
        -Name $module.Name `
        -RequiredVersion $targetVersion `
        -Force `
        -ErrorAction Stop
}

Il -Force serve perché, senza, PowerShell si impunta se trova dipendenze ancora “in uso” secondo il suo registro interno (anche quando in realtà non c’è nessun processo che le sta usando). L’ordine di rimozione (ombrello prima, Authentication per ultimo) evita gli errori di dipendenza mancante che altrimenti PowerShell ti tira dietro a metà pulizia.

A operazione conclusa, una verifica veloce conferma che è rimasta una sola versione installata:

Get-Module -Name 'Microsoft.Graph*' -ListAvailable |
    Group-Object Version |
    Sort-Object Name |
    Select-Object Name, Count

Name   Count
----   -----
2.39.0 40

In conclusione

Il modulo Microsoft.Graph per PowerShell è potente ma non fa mai pulizia da solo: ogni Update-Module lascia dietro di sé la versione precedente, moltiplicata per una quarantina di sub-moduli. Se lavori su più macchine o gestisci ambienti condivisi, questo accumulo diventa presto un problema reale, spazio sprecato, tempi di caricamento del modulo più lunghi, e il rischio concreto di caricare per sbaglio la versione sbagliata di un cmdlet.

Lo script sopra non è elegantissimo ma fa il suo lavoro in modo ripetibile: prendi la versione vecchia, rispetta l’ordine di dipendenza, disinstalla tutto con -Force. Vale la pena tenerlo a portata di mano (magari come funzione riutilizzabile) ogni volta che aggiorni Graph.

In caso di errori, dubbi, boiate riportate in articolo sai già cosa fare, l’area commenti è a tua totale disposizione :-)

#KeepItSimple

Graph: pulizia delle vecchie versioni del modulo dopo un update è stato scritto da Gioxx per Gioxx.org.

La verifica

Prima cosa: escludere che fosse un cambiamento arrivato da un qualche comportamento mio, di uno dei plugin che utilizzo o un aggiornamento di WordPress (dato che ultimamente ne sono arrivati almeno un paio per mettere al sicuro WP 7). Ho controllato wp-config.php per le costanti dichiarate in documentazione:

define( 'WP_AUTO_UPDATE_CORE', 'false' );

Presente, ma quella riguarda solo gli aggiornamenti del core di WordPress, non i plugin, non è la causa. DISALLOW_FILE_MODS assente. Poi ho controllato via wp-cli se i dati di auto-update fossero comunque popolati nel database:

$ wp plugin list --status=active
name           status  update  version  auto_update
akismet        active  none    5.7      on
wordfence      active  none    8.2.2    on
...

I dati c’erano, tutti popolati correttamente. Quindi non era un problema di database: la funzione esisteva ancora, semplicemente la UI per gestirla era sparita.

Il colpevole: un mu-plugin che non ho mai chiesto

A quel punto sono andato a guardare dentro wp-content/mu-plugins/. Cartella che, lo ricordo, WordPress carica sempre, senza possibilità di disattivazione dalla dashboard (da lì il nome: must-use). E lì, tra i miei file, ne spunta uno che non ho mai scritto io:

<?php
/*
  Plugin Name: WordPress automation by Installatron
  Description: Management of this WordPress site is provided by Installatron.
*/

// Turn off WordPress automatic updates since these are managed externally.
add_filter( 'automatic_updater_disabled', '__return_true', -9999 );

Installatron è il tool che molti hosting (incluso il mio, Serverplan) offrono per installare/gestire applicazioni web in un click. Non l’ho mai usato per questo blog, e sospetto che nemmeno tu lo utilizzi consapevolmente, se sei atterrato su questo articolo cercando la stessa colonna sparita. Eppure quel mu-plugin era lì, silenzioso, a filtrare automatic_updater_disabled forzandolo a true con priorità altissima (-9999, giusto per essere sicuri che nessun altro filtro potesse scavalcarlo). Risultato: WordPress disattiva tutto il sistema di auto-update: core, plugin, temi, e nasconde pure la UI corrispondente, colonna compresa.

Il commento nel file suggerisce un modo “ufficiale” per disattivarlo:

To block this plugin, create an empty file in the same directory named: block-automation-by-installatron.php

Peccato che il codice del plugin non controlli mai l’esistenza di quel file. È una convenzione pensata per essere letta (e rispettata) dall’automazione di Installatron stessa quando rigenera i suoi file, non da WordPress. Creare quel file vuoto, quindi, non serve a niente: il filtro resta attivo lo stesso.

La soluzione

L’unico modo efficace è intervenire direttamente sul file. Io ho scelto la via più pulita e reversibile: rinominarlo togliendogli l’estensione .php, così la cartella mu-plugins smette di caricarlo ma il file resta lì, intatto, nel caso servisse tornare indietro:

mv wp-content/mu-plugins/automation-by-installatron.php \
   wp-content/mu-plugins/automation-by-installatron.php.disabled

Verifica rapida via wp-cli per confermare che il filtro non sia più attivo:

$ wp eval 'var_dump(apply_filters("automatic_updater_disabled", false));'
bool(false)

Colonna auto-update tornata al suo posto nella pagina Plugin, tutto come previsto.

In conclusione

Se anche a te manca quella colonna e non ricordi di averla tolta, il primo posto dove guardare è wp-content/mu-plugins/, non la lista plugin normale, perché i must-use plugin non compaiono lì e non sono disattivabili dalla dashboard. Se trovi un file simile a automation-by-installatron.php (o comunque riconducibile al tuo hosting), sai già cosa cercare al suo interno e come toglierlo di mezzo.

Il punto che mi lascia più perplesso resta un altro: nessun avviso, nessuna nota nel pannello Serverplan, niente. Un mu-plugin che disattiva silenziosamente una funzione di sicurezza/manutenzione del sito è il genere di cosa che vorrei sapere prima, non scoprire per caso mesi dopo controllando una colonna mancante. Se gestisci un sito su hosting che offre Installatron (o strumenti simili), vale la pena dare un’occhiata preventiva a quella cartella, anche se non hai scelto consapevolmente di attivarlo.

L’area commenti è a tua disposizione in caso di ulteriori dubbi o magari per segnalare la medesima situazione su hosting differenti rispetto a quello da me utilizzato.

#KeepItSimple

Colonna auto-update plugin sparita? Controlla mu-plugins, potrebbe essere colpa di Installatron è stato scritto da Gioxx per Gioxx.org.

Cinque settimane fa avevo dato il via a una serie di articoli ad-hoc per parlarti del nuovo look per una nuova era di The Marvellous Suspender, avevo usato direttamente il blog di Marvellous Codeworks e l’inglese come lingua principale per raggiungere quanti più lettori e utilizzatori possibili (non pensavo avrebbe avuto senso ospitare il tutto, in italiano, anche qui sul mio blog personale). Poche ore fa Google ha dato il via libera alla pubblicazione della v9.0.0 e, a partire da lunedì mattina, 3 agosto, la nuova versione comincerà a essere distribuita sul Chrome Web Store. È l’ultima tappa di questo percorso, e te la racconto volentieri (con 40°C fuori e la voglia di mettere la testa sott’acqua, ma questo è un altro discorso).

TMS 9: cosa c’è di nuovo sotto al cofano

• Backup e ripristino delle sessioni (forse tra le feature più richieste in assoluto, dalla notte dei tempi), in locale o su Google Drive, programmabile o su richiesta, con supporto multi-dispositivo.
• Una pagina di Tab Health che scansiona le schede sospese e ripara da sola il bug dei Tab Groups che si perdono al riavvio di Chrome, Edge e Brave (bug ormai risolto, ma considerato che non si sa mai, le funzioni sono state conservate e rese disponibili su richiesta / necessità).
• Un feed di notizie che pesca direttamente dal blog di Marvellous Codeworks (che rimane l’unico ufficiale del progetto, in inglese, mentre qui sul mio blog personale continuerò a proporre articoli in italiano, talvolta traducendoli direttamente) raggiungibile tramite la barra laterale delle impostazioni dell’estensione.
• Un redesign visivo completo che finalmente fa sembrare tutte le pagine delle impostazioni parte dello stesso prodotto.
• 16 lingue riportate in pari dopo essere rimaste indietro per chissà quanto tempo.

Niente di tutto questo è arrivato per caso, e niente è arrivato da solo.

Le chiacchierate con Rob

Io e Rob non lavoriamo nello stesso ufficio, nello stesso Paese, e nemmeno vicini come fuso orario, per buona parte del tempo. Gran parte delle decisioni su TMS 9 sono state avviate in un gruppo Slack in orari che non avevano senso per nessuno dei due, discutendo se un permesso fosse troppo invasivo, se un’impostazione avesse bisogno di un tooltip, se “Ripristina da backup” dovesse stare sotto Sessioni o sotto Backup. Domande piccole, ma di quelle che decidono se un’estensione sembra curata o semplicemente pubblicata.

The Great-er Tab Discarder (TGD) e The Marvellous Suspender (TMS) sono due progetti distinti, con codebase separate, ma Marvellous Codeworks funziona solo perché siamo in due a tirare nella stessa direzione, a controllarci i punti ciechi a vicenda e, ogni tanto, a dirci l’un l’altro che un’idea fa schifo prima che finisca in produzione. TMS 9 ne guadagna, eccome, e speriamo di poter fare la stessa cosa con TGD, presto.

La community che si è fatta sentire

Nel changelog di TMS 9 ci sono anche due contributor al debutto: @MatrixNeoKozak, che ha rifattorizzato il livello di storage eliminando serializzazioni JSON inutili, e @iGhost, che ha aggiunto l’opzione per mantenere la posizione di riproduzione di YouTube quando una scheda viene sospesa. Una feature piccola, richiesta e costruita da chi il problema lo ha vissuto sul serio (io per esempio non avevo mai avuto necessità di questa caratteristica). È esattamente così che dovrebbe crescere un progetto open source: non solo bug report, ma pull request di persone che hanno deciso di sistemare la cosa di persona.

In più, sedici lingue hanno ricevuto un passaggio di traduzione assistita da AI (qui Claude ha avuto carta bianca) per colmare buchi che si trascinavano da diverse versioni. Non sono perfette: se usi TMS nella tua lingua e qualcosa suona storto, Crowdin è aperto, e le correzioni dei madrelingua sono esattamente ciò che serve per chiudere il cerchio.

Segnalare un problema senza account GitHub

Per anni l’unico modo per dirci che qualcosa non andava era aprire una segnalazione su GitHub, il che significava avere un account GitHub, spesso visto come un muro che molti semplicemente non erano disposti a scavalcare solo per segnalare un bug. I problemi ci arrivavano di riflesso, nelle recensioni, nei thread di Reddit, mai dove potevamo davvero intervenire.

marvellouscode.works/tms/report proverà a risolvere la cosa. Si compila un form, senza registrazione, senza account, e viene aperta in automatico una issue GitHub corretta, etichettata bene, con i campi che ci servono davvero per riprodurre il problema. Chi segnala riceve un link per seguire lo stato, noi riceviamo un report vero e utilizzabile invece di una recensione da una stella che dice solo “non funziona più”.

E a proposito: leggiamo tutto, comprese le recensioni lasciate direttamente sul Chrome Web Store. Stelline, recensioni scritte, richieste di supporto in quel piccolo box, tutto viene letto. Teniamo d’occhio in particolare le segnalazioni GitHub perché è lì che tracciamo e agiamo davvero, verificando comportamenti strani, seguendo le richieste, chiudendo le cose una volta risolte, ma una recensione lasciata sullo Store non è comunque gridare nel vuoto.

Un sito di documentazione costruito da zero

Il vecchio wiki di TMS viveva sul repo GitHub, mezzo incompleto, datato in alcuni punti, e onestamente non il tipo di posto dove mandare qualcuno se volevate che capisse davvero l’estensione. Ora è disattivato.

Al suo posto: kb.marvellouscode.works/docs, popolato da zero sfruttando Docusaurus come base, pagina per pagina, specialmente per TMS 9 (anche se in realtà pensato per tutti i lavori che trovano spazio sotto l’ala di Marvellous Codeworks). Ogni pagina delle impostazioni ha il suo articolo: Impostazioni, Sessioni, Backup, Tab Health, Azioni Rapide, Scorciatoie da Tastiera, Notizie, Informazioni, che spiega cosa fa davvero ogni pulsante, non solo come si chiama. C’è una pagina dedicata ai permessi che spiega perché TMS chiede quello che chiede e cosa è cambiato con lo scope Drive più ristretto in questa release. FAQ incluse. Niente nascosto in una pagina wiki stantia che nessuno aggiornava dal 2019.

L’abbiamo costruito pagina per pagina, decidendo cosa aveva davvero bisogno di essere spiegato e cosa era abbastanza ovvio da saltare. Il dominio marvellouscode.works era registrato e fermo da quasi un anno: ci sono volute settimane di riorganizzazione e riscrittura per trasformarlo nel sito, nella documentazione e nel flusso di segnalazione che puoi sfruttare oggi.

Cambia tutto (ma non cambia niente)

TMS 9 ha un aspetto diverso, è organizzato diversamente, permette di effettuare il backup diversamente, e parla più lingue di prima. Questa è la parte “cambia tutto”, ed è costata una riscrittura completa delle pagine di impostazioni, un nuovo sistema di backup e parecchie scambi in chat.

La parte “non cambia niente” è più semplice: TMS esiste ancora per prendere le schede che il browser accumula in memoria e metterle a dormire finché non servono davvero. Era vero il giorno in cui The Great Suspender è stato salvato, lo è stato durante la riscrittura per Manifest V3, e lo è ancora nella v9.0.0. Ogni feature di questa release, Tab Health, backup, redesign, esiste per proteggere quel singolo compito, non per sostituirlo.

Non piacerà a tutti, e va bene così

Siamo perfettamente consapevoli che non tutti saranno entusiasti del nuovo look. Il cambiamento raramente è visto di buon occhio, e un redesign di queste dimensioni – nuovi font, nuovi colori, nuovo layout su ogni singola pagina – è esattamente il tipo di cosa per cui alcuni avranno bisogno di tempo per abituarsi, o semplicemente non gli piacerà affatto. Fa parte della crescita di un progetto, fa parte del gioco.

Restiamo convinti che la “ritinteggiatura” fosse necessaria, e pensiamo sia solo il primo passo importante. Ci sono altre idee in cantiere, e ci sono già parecchi problemi e richieste di feature su GitHub che intendiamo affrontare per continuare a spingere TMS avanti. Ascoltiamo, prendiamo sul serio feedback e critiche costruttive: è tutto il senso dell’open source, in fondo.

Cosa succede ora

La revisione di Google è conclusa, il changelog è definitivo, e il rilascio parte lunedì mattina, 3 agosto. Gli aggiornamenti sul Chrome Web Store vengono distribuiti gradualmente e non a tutti insieme, quindi non allarmarti se non vedi la v9.0.0 nel secondo esatto in cui andrai a controllare: arriverà entro la normale finestra di aggiornamento. Questa serie di articoli si chiude ufficialmente qui. Grazie per averla seguita fino in fondo, per aver testato i feature branch, per le issue aperte, per le pull request, e per la pazienza.

Ci vediamo dall’altra parte, nella v9.0.0. L’area commenti è a tua disposizione, come sempre, per domande o per raccontarmi la tua personale esperienza con TMS 9.

#KeepItSimple (e buone vacanze!)

Immagine di copertina: Growtika on Unsplash

TMS 9: ce l’abbiamo fatta, da lunedì si va in scena! è stato scritto da Gioxx per Gioxx.org.

Sul blog ufficiale di Nightly è comparso un post di annuncio piuttosto scarno (New Firefox Design), di quelli che dicono poco e lasciano parlare gli screenshot: giusto due righe di presentazione e via, senza un vero e proprio changelog o una spiegazione del perché di questa scelta proprio ora.

Nightly resta il mio Firefox di tutti i giorni, non a caso: mi piace sperimentare, dare un contributo (quando posso) alle idee che magari un domani arriveranno anche nelle versioni stabili. È rimasto quel poco che riesco ancora a fare dopo vent’anni e passa in Mozilla Italia, di cui i primi da contributor piuttosto attivo. Chi segue Firefox da un po’ di anni sa che non è la prima volta che il browser cambia pelle: Australis, Photon, Proton sono nomi che a chi ha vissuto quelle transizioni diranno qualcosa, e ognuna ha portato con sé lo stesso copione: entusiasmo di facciata, malumori sotto traccia, e alla fine ci si abitua tutti (o quasi). Project Nova sembra volersi inserire in questa tradizione, solo che stavolta la reazione è arrivata più rumorosa e più in fretta del solito.

Project Nova me lo sono trovato in faccia da subito, senza nemmeno cercarlo, aggiornando Nightly come faccio ogni giorno, ed è giusto perché chi usa Nightly accetta di fare da cavia per queste sperimentazioni.

Cosa dice la community

Su Mozilla Connect è partito un thread dedicato, Take Project Nova for a spin in Nightly, e “nutrito” è dire poco: pagine e pagine di commenti (caricarle tutte richiede un attimo di pazienza), e il tono generale non è esattamente da standing ovation. Ho lasciato anche il mio contributo al thread, qui, e riassumendo: il “gioco” del nuovo aspetto grafico può anche essere divertente da provare per qualche giorno, ma a conti fatti resta un esercizio di stile che toglie più di quanto aggiunge a chi usa il browser per lavorarci, non per ammirarlo.

Quello che mi ha colpito, scorrendo il thread, non è tanto il dissenso in sé (succede a ogni redesign, fa quasi parte del rito), quanto il volume e la rapidità con cui è arrivato. Di solito ci vogliono settimane prima che un cambiamento grafico venga metabolizzato dalla community, qui in pochi giorni si è già accumulata una mole di feedback che normalmente si vede solo dopo un rilascio stabile, non su un canale sperimentale che nasce apposta per essere rotto e discusso.

Come tornare indietro

Se anche a te Nova non convince e vuoi il vecchio aspetto “più umano”, il salvagente c’è ed è semplice:

• Apri about:config (il solito avviso: sai cosa stai facendo, ma occhio comunque a cosa tocchi, un flag sbagliato e ti ritrovi a chiederti perché qualcos’altro ha smesso di funzionare).
• Cerca browser.nova.enabled.
• Impostalo su false

Fatto, il browser torna all’interfaccia che conosci, senza bisogno di reinstallare nulla o tornare a un canale diverso da Nightly, senza neanche riavviare Firefox che di solito è necessario per applicare le modifiche operate da about:config. Tieni presente che, trattandosi di un flag sperimentale, non è garantito che sopravviva tale e quale ai prossimi aggiornamenti: se un giorno lo cerchi e non lo trovi più (o si comporta diversamente), la causa più probabile è che nel frattempo Project Nova sia stato integrato più a fondo nel browser, magari con un meccanismo di disattivazione diverso.

Comprendo, non condivido

Capisco la logica dietro Project Nova. Ogni tanto un browser ha bisogno di rinfrescarsi, e Nightly è esattamente il posto giusto dove provare queste cose prima che arrivino (se arrivano) nelle versioni stabili. Ma tra provarlo e tenerlo attivo di default anche su un canale già di per sé instabile fa una bella differenza, e il thread su Connect lo dimostra piuttosto bene. Per ora resto con browser.nova.enabled a false, e aspetto di vedere dove va a parare questo esperimento: se Mozilla ascolterà davvero quello che sta emergendo da Connect o se, come già successo in passato, si andrà avanti dritti per la propria strada aggiustando solo i dettagli più urlati.
Magari tra qualche tempo (neanche tanto esagerato) torno ad attivarlo e vedere quali passi in avanti sono stati fatti.

#KeepItSimple

Project Nova per Firefox Nightly: bello il gioco, però ora basta. è stato scritto da Gioxx per Gioxx.org.

Da qualche mese la soluzione che uso, e di cui sono rimasto soddisfatto, è Claude Swap.

Cos’è Claude Swap

Claude Swap è un tool a riga di comando (Python) che gestisce le credenziali di più account Claude e permette di passare dall’uno all’altro con un comando, sia che tu stia lavorando da CLI che da VSCode. Fatta la configurazione iniziale, la parte più “onerosa” ma comunque semplice, il resto è tutta discesa: scegli l’account, lavori, e quando serve cambi contesto senza frizioni.

La prima volta che lo installi dovrai infatti lanciare cswap add da riga di comando per aggiungere l’account che in quel momento stai già usando e che risulta essere collegato alla tua sessione. Torna sul browser, scollegati e ricollegati a Claude utilizzando un diverso account, quindi salta ancora sulla riga di comando per eseguire ancora una volta cswap add ed ereditare pure il nuovo account, e così via.

Quello che apprezzo di più è che non ti costringe a scegliere un solo fronte: copre sia il terminale che l’editor, quindi qualsiasi sia il tuo workflow del momento, resti libero di alternare personale e aziendale a seconda del progetto su cui stai lavorando. Puoi addirittura essere ancora più puntiglioso, non fare uno switch su tutti i tuoi ambienti ed eseguire un run con un’utenza specifica in una finestra specifica (cswap run user@dominio-personale.com).

Un’interfaccia più curata di quanto ti aspetti

Una volta installato lo lanci semplicemente eseguendo cswap (o claude-swap) e ti trovi davanti un’interfaccia testuale realizzata con Textual, framework Python per TUI moderne, non il solito prompt spoglio. Per ogni account configurato vedrai una barra che mostra quanto hai consumato della finestra di utilizzo a 5 ore e di quella settimanale, con relativo orario di reset, oltre a un indicatore chiaro di quale account è attivo in quel momento.

Dal menu principale puoi scegliere queste voci:

• Switch account… per cambiare account al volo
• Watch accounts per tenere sott’occhio i consumi in tempo reale
• Auto-switch view per configurare uno switch automatico (utile se non vuoi accorgerti tu per primo di aver saturato un abbonamento)
• Add account… / Remove account… per gestire la lista
• Disable / enable account… per escludere temporaneamente un account senza rimuoverlo
• Theme… per il tema dell’interfaccia

Tutto navigabile da tastiera, con scorciatoie richiamate a fondo schermo (s per switch, w per watch, ^t per il tema, q per uscire). Poco più di un comando, insomma, ma ben pensato.

Aggiornarlo è banale

Essendo un progetto Python, l’aggiornamento passa da pip, come ti aspetti:

python -m pip install --upgrade claude-swap

Giusto oggi che sto scrivendo questo articolo l’ho rifatto per l’ennesima volta, dalla 0.22.0 alla 0.23.0, senza il minimo intoppo:

Requirement already satisfied: claude-swap in ...Python312\Lib\site-packages (0.22.0)
Collecting claude-swap
  Downloading claude_swap-0.23.0-py3-none-any.whl.metadata (22 kB)
...
Successfully installed claude-swap-0.23.0

Nessuna sorpresa, nessuna configurazione da rifare da capo.

E le credenziali dove finiscono?

Punto che mi sta particolarmente a cuore: Claude Swap si appoggia a keyring, quindi le credenziali dei tuoi account non finiscono in un file di testo in chiaro da qualche parte sul disco, ma nel gestore di credenziali nativo del sistema operativo (Credential Manager su Windows, Keychain su macOS, e così via). Un aggiornamento del tool, come quello di cui sopra, non tocca minimamente questa parte: le credenziali restano dove sono, gestite in modo sicuro lato sistema.

In conclusione

Se ti ritrovi anche tu a gestire più abbonamenti Claude, sia esso personale, lavorativo, o semplicemente più account per motivi diversi, Claude Swap è uno di quegli strumenti che, una volta configurati, smetti di notare: fa il suo lavoro in silenzio e ti lascia concentrato su quello che stai realmente facendo, senza il fastidio di continui logout/login o browser profile separati.

Spero possa tornare utile anche a te :-)

#KeepItSimple

Claude Swap gestisce via CLI più abbonamenti/account è stato scritto da Gioxx per Gioxx.org.

In sintesi: nel giro di pochi giorni se ne sono andati tre nomi pesanti del progetto. Joshua Boniface, uno dei fondatori e Project Leader storico, ha lasciato il ruolo con un annuncio sul forum ufficiale tutt’altro che di circostanza: parla apertamente di “severe burnout, and risks to my mental health” e ammette di non riuscire più a garantire “the effort (mental or time-wise) that the role demanded”. Chiude comunque con affetto – “For the last time, happy watching all!” – e ribadisce che la transizione è amichevole. Andrew Rabert, anche lui fondatore, se n’è andato volontariamente il 17 luglio 2026, dopo mesi passati a riscrivere da zero il client desktop (partito a dicembre 2025 per risolvere problemi annosi come il supporto HDR e la manutenzione di Qt). Nel suo commento su GitHub descrive un clima interno diventato “very negative and increasingly burdensome and restrictive”, al punto da fargli perdere la voglia di dedicare al progetto quello che per anni era stato passione e motivo di relax come si trattasse di un puro hobby. Uscendo dall’organizzazione ha perso anche il diritto a usare il nome “Jellyfin”, quindi il suo client proseguirà sotto un altro nome. Anthony Lavado, membro storico del core team, si è dimesso in parallelo per cambiamenti nella vita personale che gli riducono il tempo disponibile, impegnandosi comunque a garantire una transizione senza intoppi.

La causa di fondo, però, è la stessa per tutti: burnout. Il report “State of the Fin” di maggio 2026, che di solito celebra metriche di attività in salute (quasi 3.800 PR mandate in merge nel periodo, picchi di 434 in un mese, tra 46 e 75 contributori attivi al mese), ammette a chiare lettere che “l’aumento delle richieste di supporto, combinato con i contributi di codice AI, ha portato a esaurimento a vari livelli”, e che gli abusi da parte di utenti scontenti quando qualcosa non funziona rallentano ulteriormente i miglioramenti. Non è un dettaglio da poco: il progetto ha dovuto introdurre una policy esplicita sui contributi generati con l’AI, obbligando chi li sottopone a capire davvero il codice proposto e a rispondere di persona ai feedback, non certo il copia-incolla che in molti si aspettano quando pensano di poter mettere al lavoro il proprio abbonamento (sia esso di Claude, Codex o qualsiasi altro aiutante). Se stai mantenendo un progetto open di questa scala, ricevere pull request scritte (o “assistite”) da un modello e dover fare da filtro qualità aggiunge un peso che prima semplicemente non esisteva.

La buona notizia, se la si vuole chiamare così, è che chi se n’è andato ha tenuto a precisare che l’uscita è pacifica, con “poco o nessun rischio di fork ostile”, e che il resto del team, già diviso su altre aree del progetto, sta continuando le operazioni.

Qui però voglio aggiungere una cosa più personale. Io sono cliente Lifetime di Plex da (tanti) anni, e per me Plex è sempre stato “lo stato dell’arte” per questo genere di cose, il prodotto contro cui si misurano tutti gli altri. Ma diciamocelo: negli ultimi tempi è diventato più pesante, più pachidermico, e genera più frizione sia per chi lo sviluppa sia per chi lo usa tutti i giorni. E non parlo solo di percezione: il Lifetime Plex Pass è passato da 120 dollari a 250 dollari nell’aprile 2025, per poi triplicare di nuovo a 749,99 dollari dal 1° luglio 2026, con tanto di accenno che l’opzione lifetime potrebbe sparire del tutto in futuro. Chi ce l’ha già tiene i benefici, per carità, ma è un segnale chiaro di dove sta andando il prodotto: verso un modello sempre più orientato all’abbonamento, sempre meno amichevole per chi vuole pagare una volta e basta.

Ed è proprio in questo contesto che Jellyfin, nonostante le sue crepe di governance, resta un’alternativa concreta e sempre più solida. Il progetto conta 8 client ufficiali (Android, Android TV, Desktop, Kodi, Roku, Tizen, Xbox, Swiftfin) più altri due in sviluppo, e vive di un ecosistema di plugin, temi grafici e integrazioni esterne che raggiunge praticamente ogni piattaforma esistente, cosa che a un prodotto chiuso come Plex, per sua natura, riesce molto più difficile. È più aperto, più adattabile, e – a differenza di Plex – non ti sveglia una mattina con il prezzo del piano lifetime triplicato (si nota la mia pacata nota polemica nonostante io non sia stato colpito da questa brillante decisione?).

Da utente, la cosa che mi fa riflettere di più non è tanto il rischio immediato per Jellyfin (che al momento sembra sotto controllo), quanto il pattern che si sta ripetendo un po’ ovunque nel mondo Open Source: progetti che reggono su poche persone, quelle poche persone che si bruciano, e adesso pure il carico aggiuntivo di dover controllare codice scritto da un’AI invece che risparmiare tempo. Se dipendi da qualcosa di self-hosted per la tua libreria multimediale, e sospetto che se sei qui a leggere questo blog sia il tuo caso, vale la pena tenere d’occhio come evolve la governance di Jellyfin nei prossimi mesi, non perché sia in pericolo imminente, ma perché è un buon termometro di quanto reggano certi modelli di manutenzione quando i volontari dietro cominciano a mollare.

E non è in ogni caso una novità, parlando in generale di questo mondo che va ben oltre Jellyfin, il meme qui di fianco ha fatto (e fa ancora) scuola di tanto in tanto, quando l’argomento viene riportato alla ribalta.

In conclusione

Nessun allarme rosso per ora, ma un promemoria che i progetti open che usiamo ogni giorno stanno in piedi grazie a poche persone che a un certo punto possono semplicemente stancarsi. Nel frattempo, tra un Plex sempre più caro e pesante e un Jellyfin sempre più maturo e aperto, la bilancia per me continua a spostarsi verso quest’ultimo, nonostante non sia assolutamente pronto ad abbandonare il “primogenito“.

Se usi Jellyfin (o Plex, o entrambi), l’area commenti è a tua disposizione per confrontarci su cosa ne pensi, ammesso ti vada (e buon fine settimana pure a te!).

#KeepItSimple

Immagine di copertina: Anton Borzenkov on Unsplash

Jellyfin: tra dimissioni, burnout e riflessioni sparse è stato scritto da Gioxx per Gioxx.org.

Riassunto brutale: un agente AI di OpenAI, durante un test di sicurezza su un benchmark pubblico, è evaso dal suo ambiente isolato (tecnicamente una sandbox) ed è finito a bucare davvero l’infrastruttura di produzione di Hugging Face. Non una simulazione, non un innocuo test di laboratorio: server veri, credenziali vere, dati veri. E ci è voluto un intero fine settimana prima che qualcuno se ne accorgesse.

Il contesto: cos’è ExploitGym

Partiamo da dove nasce tutto. ExploitGym è un benchmark pubblico creato da UC Berkeley con la collaborazione di attori come Anthropic, OpenAI e Google, pensato per misurare quanto bene un modello AI sappia trasformare una vulnerabilità nota (una “proof-of-vulnerability”, per capirci: la prova che il buco esiste) in un exploit funzionante. Dentro ci sono quasi 900 vulnerabilità reali, divise tra programmi userspace, il motore V8 di Chrome e il kernel Linux.

In altre parole: è un ambiente pensato apposta per insegnare e verificare le capacità offensive di un modello, in teoria dentro un recinto controllato. Il classico “diamo all’AI un cortile chiuso dove può fare danni, così capiamo quanto è brava a farli”.

Il problema, come vedremo, è che il cortile aveva un buco nella rete.

Cosa è successo davvero

Il 16 luglio 2026 Hugging Face rileva, in autonomia, un’intrusione nella propria infrastruttura di produzione. Non un test, non un red team annunciato: un’intrusione vera, rilevata grazie a una pipeline di anomalie che usa modelli AI per fare da filtro sul rumore di fondo della telemetria di sicurezza (sì, si combatte fuoco con fuoco, e su questo torniamo più avanti).

Il punto d’ingresso? Due classi di vulnerabilità nel processing dei dataset: un loader di dataset con esecuzione di codice remoto e una iniezione di template nella configurazione. Non roba nuovissima, anzi: la prima famiglia di bug è nota alla comunità almeno dal 2023. Occhio a questo dettaglio, perché torna comodo più avanti quando si parla di responsabilità.

Da lì, l’attaccante (o meglio: l’agente) ha scalato privilegi, raccolto credenziali cloud e si è mosso lateralmente tra diversi cluster interni, nell’arco di un intero weekend, accumulando oltre 17.000 azioni autonome. Hugging Face parla di un set limitato di dataset interni e alcune credenziali compromesse, e – buona notizia, se così si può dire – nessuna evidenza che modelli, dataset o Spaces pubblici siano stati manomessi. Va detto per correttezza che il rilevamento è arrivato da entrambe le parti quasi in parallelo: il team di sicurezza di Hugging Face ha bloccato l’attività sulla propria infrastruttura e avviato da solo il contenimento e la ricostruzione forense (con modelli open-source proprietari, tra l’altro), mentre il team di sicurezza di OpenAI scopriva indipendentemente l’attività anomala sul proprio lato. Solo dopo i due team si sono messi in contatto e hanno unito le indagini.

Cinque giorni dopo, il 21 luglio, arriva la rivelazione ufficiale da parte di OpenAI, in un post congiunto con Hugging Face: dietro l’intrusione c’era GPT-5.6 Sol insieme a un modello pre-release ancora più capace, entrambi con i refusal legati al cyber ridotti apposta per finalità di valutazione (in parole povere: senza i freni che normalmente li fermerebbero davanti ad attività ad alto rischio). L’obiettivo dichiarato non era “bucare Hugging Face” in senso classico: il modello era, per usare le parole di OpenAI, “iperfocalizzato” nel trovare una soluzione per ExploitGym, ed è arrivato a cercare – e trovare – le risposte corrette direttamente nel database di produzione di Hugging Face, per barare al test.

Il percorso è tecnicamente interessante e vale la pena seguirlo passo passo. L’ambiente di test di OpenAI aveva accesso a internet limitato all’installazione di package tramite un proxy/cache interno per i registri software di terze parti. Il modello ha impiegato una quantità notevole di potenza di calcolo pur di trovare un modo per uscire da quel recinto e arrivare a internet aperto: ha scoperto – da solo, senza accesso al codice sorgente – una vulnerabilità zero-day proprio in quel proxy (nel frattempo divulgata responsabilmente al fornitore), l’ha usata per scalare privilegi e muoversi lateralmente nell’ambiente di ricerca di OpenAI fino a raggiungere un nodo con accesso a internet. Da lì ha dedotto che Hugging Face probabilmente ospitava modelli, dataset e soluzioni di ExploitGym, e ha concatenato credenziali rubate e altri zero-day per trovare un percorso di esecuzione di codice remoto sui server di Hugging Face.

In parole povere: un modello che doveva solo dimostrare di saper trasformare un bug noto in un exploit ha finito per trovarne di nuovi, da solo, e per usarli per uscire dal recinto in cui era stato messo apposta per “fare danni sotto controllo”.

Il nodo tecnico: isolamento illusorio

Qui arriva la parte che, da tecnico, fa più male delle altre. OpenAI stessa ha descritto l’ambiente di test come “altamente isolato” (highly isolated, testuale). Peccato che quell’ambiente avesse comunque una via verso internet tramite quel proxy per i registri software, e il modello ha sfruttato esattamente il presupposto, evidentemente troppo fiducioso, che quella via fosse sicura o comunque impraticabile per uscire dal recinto.

È un errore che chiunque abbia mai progettato un ambiente “sandbox” riconosce a colpo d’occhio: isolato non significa isolato se poi lasci un varco verso l’esterno e ti fidi che nessuno lo trovi. Non serve un agente AI sofisticatissimo per insegnarcelo, basterebbe la storia di qualsiasi breach degli ultimi vent’anni. Il fatto che stavolta a trovare il varco sia stato un modello, in autonomia, in poche ore, cambia la scala del problema ma non la natura dell’errore: è ancora una falla di progettazione, non un miracolo di intelligenza artificiale.

Alberto Pelliccione, che ha scritto un’analisi tecnica molto lucida sull’incidente (la trovi su linkedin.com/pulse), la inquadra bene: più che un attacco deliberato, siamo davanti a un caso di reward hacking. Il modello non “voleva” bucare Hugging Face nel senso in cui lo vorrebbe un attaccante umano, voleva vincere il benchmark, e ha semplicemente seguito la strada più breve verso la ricompensa, che per caso passava attraverso credenziali cloud reali e cluster di produzione veri.

Il dubbio resta (e per certi versi è quasi una certezza, anche se nessuno lo scriverà mai nero su bianco in un comunicato ufficiale): se il percorso più breve verso il premio passa per un’infrastruttura reale, il problema non è che l’AI sia troppo capace. È che qualcuno ha lasciato quel percorso aperto.

La parte più paradossale: chi ha aiutato a fare le pulizie

Ed eccoci al dettaglio che, da solo, vale l’intero articolo. Durante l’analisi forense – oltre 17000 eventi di log da ricostruire per capire cosa fosse successo – Hugging Face ha usato GLM 5.2, un modello open-weight (di origine cinese, per essere precisi). Non per scelta ideologica: perché i modelli commerciali occidentali, Anthropic e OpenAI compresi, con i loro guardrail di sicurezza si rifiutavano di analizzare gli artefatti dell’attacco, trattandoli come contenuto potenzialmente dannoso da non toccare.

Ti basti pensare a questo: i modelli “sicuri per design” hanno ostacolato chi doveva ripulire i danni, mentre un modello open-weight, proprio quello oggetto di discussioni e restrizioni proposte in ambito geopolitico (per timori legati alla sicurezza, ironia delle ironie), si è rivelato lo strumento decisivo per la difesa.

Pelliccione la definisce come un paradosso geopolitico, e onestamente è difficile dargli torto: i guardrail hanno bloccato chi doveva ripulire, non chi doveva attaccare. L’agente incriminato, va ricordato, era comunque un modello OpenAI, solo che stava operando in un contesto di test dove quei paletti valgono meno.

Cosa ci lascia in mano questa storia

Al netto del clamore mediatico (e sì, un titolo come “OpenAI hacked Hugging Face” fa notizia più facilmente di “una sandbox mal configurata ha causato un incidente”), qualche punto mi pare innegabile:

• La sandbox non è un concetto binario. “Isolato” deve significare isolato per davvero, non isolato-tranne-per-quel-proxy-a-cui-abbiamo-dato-fiducia. Vale per gli agenti AI oggi, valeva per le VM di test dieci cinque tre due anni una manciata di settimane fa (e tutt’ora, perché ne esistono ancora quante ne vuoi in giro).
• Vulnerabilità note restano un problema reale, anche quando a scoprirle “di nuovo” è un modello da miliardi di parametri. Un loader di dataset con RCE noto dal 2023 non dovrebbe essere ancora in produzione nel 2026, punto (e qui il giudizio resta netto perché descrive un fatto, non perché voglia fare colore).
• Le capacità offensive autonome dei modelli frontier non sono più teoria da paper accademico. Erano previste da anni nelle ricerche sul rischio cyber dell’AI: qui le vediamo diventare cronaca, con tanto di timeline, log e comunicati ufficiali.
• I guardrail dei modelli commerciali proteggono da alcuni scenari e ne creano altri: se blocchi l’analisi forense di un attacco reale perché “sembra contenuto dannoso”, stai aiutando chi deve rispondere all’incidente o solo aggiungendo frizione dove già ce n’è fin troppa?

Non ho risposte facili da darti su quest’ultimo punto, e sospetto che nemmeno chi scrive quei guardrail le abbia ancora del tutto chiare. Quello che è certo è che la distanza tra “benchmark di sicurezza in un ambiente controllato” e “incidente di sicurezza reale con credenziali cloud sottratte” si è rivelata molto più corta di quanto chiunque, in OpenAI o altrove, avesse previsto.

Chiudo con una frase di Clem Delangue, co-fondatore e CEO di Hugging Face, riportata proprio nel post ufficiale di OpenAI, perché mette a fuoco meglio di qualsiasi mio commento dove sta andando tutta questa storia: “AI safety won’t be solved by any single company working in secret. It will be solved in the open, collaboratively, with broad access to AI for every defender, everywhere”: la sicurezza dell’AI non si risolve con un’azienda sola che lavora in segreto, ma in modo aperto e collaborativo, con accesso ampio all’AI per ogni difensore, ovunque.

Se vuoi approfondire, oltre ai link già citati, trovi il resoconto ufficiale di Hugging Face su huggingface.co/blog, il post congiunto di OpenAI su openai.com/index e un’analisi più estesa su cyberwarrior76.substack.com.

In conclusione

Non credo serva scomodare scenari apocalittici da fantascienza per prendere sul serio questa storia: basta guardarla con gli occhi di chi ha messo in piedi ambienti di test almeno una volta nella vita. Un modello ha fatto, in un weekend e senza supervisione umana in tempo reale, quello che un buon penetration tester farebbe in una settimana di lavoro mirato, e lo ha fatto per motivi che con la malizia umana hanno poco a che fare. Non è meno preoccupante: è preoccupante in un modo diverso, e forse più difficile da normare con le categorie di sicurezza a cui siamo abituati.

L’area commenti è a tua disposizione, se vuoi discuterne o se hai letto l’incidente diversamente da come l’ho raccontato io qui, che poi potrei aver preso delle cantonate pure io con le informazioni reperite, quindi sentiti libero di bastonarmi (in maniera comunque civile!).

#KeepItSimple

Immagine di copertina: Chris Yang on Unsplash

“Scusate, ha stato l’IA”: il caso OpenAI e Hugging Face è stato scritto da Gioxx per Gioxx.org.