curl 8.23.0 è disponibile: verificare l’installazione effettiva e le dipendenze SMB

curl 8.23.0 è stato pubblicato il 14.10.2026. Un curl aggiornato nel terminale non dimostra che sia stata aggiornata anche la libreria libcurl di un’applicazione aziendale. I piccoli team IT con script, container e applicazioni di fornitori devono identificare la copia utilizzata, il fornitore e i criteri di accettazione funzionale. C’è inoltre una domanda concreta: qualche attività dipende ancora da SMB?

Cosa è confermato il 14 ottobre

La tabella delle versioni riporta 8.23.0 del 14.10.2026 e la pagina dei download offre gli archivi sorgenti. [1][2] La precedente indicazione di rilascio pianificato è superata; 8.23.0-rc3 non è la versione regolare. Sorgenti disponibili non dimostrano la disponibilità nel proprio canale di pacchetti né l’aggiornamento di librerie incorporate. Il numero di versione non basta neppure a valutare correzioni riportate nelle distribuzioni. Il changelog documenta la rimozione del supporto SMB. [3] Le attività con smb:// o smbs:// richiedono inventario e verifica funzionale prima della migrazione. Ciò riguarda curl, non automaticamente SMB nel sistema operativo.

Prerequisiti e limiti

Servono accesso in lettura all’inventario software e alle attività pianificate, un responsabile applicativo e un ambiente di prova separato con dati non riservati. L’inventario non richiede installazioni amministrative né sostituzioni di file di sistema. Gli aggiornamenti successivi devono seguire il canale supportato. Una libcurl inclusa in un’applicazione non coincide necessariamente con quella dello strumento da riga di comando. [4] Non copiate binari o DLL estranei nelle cartelle delle applicazioni.

Cinque passi per preparare l’intervento

  1. Inventariate gli utilizzi, non solo le versioni. Per ogni attività importante annotate applicazione, contesto di esecuzione, percorso, origine del pacchetto, responsabile e finalità aziendale. Distinguete servizi, attività pianificate, runner CI e container. Il percorso trovato nel terminale personale non dimostra cosa avvii un servizio. Per software di terzi richiedete l’elenco dei componenti o una conferma del fornitore: il solo nome di un file non basta.
  2. Identificate l’eseguibile effettivamente utilizzato. Su Windows, la query PowerShell in sola lettura Get-Command curl.exe -All aiuta a individuare gli eseguibili; su Linux/macOS, command -v curl mostra la risoluzione della shell corrente. Avviate il binario approvato e attendibile dal percorso completo con --version. curl --version riporta informazioni su librerie, protocolli e funzionalità. [5] Registrate anche backend TLS e architettura. Questo non inventaria altri processi né librerie incorporate separatamente. command -v può restituire anche una funzione della shell o un alias. Prima di controllare la versione, verificate che il percorso registrato identifichi il file eseguibile approvato.
  3. Assegnate a ogni installazione un percorso di aggiornamento. Pacchetti di sistema, immagini base dei container, strumenti autonomi e applicazioni di fornitori richiedono responsabili distinti. I distributori possono riportare correzioni su versioni precedenti; il numero upstream da solo non prova lo stato delle patch. Il giorno del rilascio confrontate avviso del fornitore, revisione del pacchetto e disponibilità effettiva. Non sostituite autonomamente libcurl in un’applicazione del fornitore. Documentate approvazioni mancanti, responsabile e data di riesame. [7]
  4. Preparate una piccola matrice di test funzionali. Scegliete un download autorizzato, un caso necessario di proxy/autenticazione e una risposta di errore controllata nell’ambiente di prova. Definite prima stato HTTP, contenuto atteso e codice di uscita: il successo del processo non garantisce dati aziendali corretti. Provate solo i protocolli necessari, senza interrogare destinazioni di produzione arbitrarie. Niente segreti nelle righe di comando o nei log condivisi. Confrontate prima e dopo usando la stessa configurazione. Novità per 8.23.0: cercate smb:// e smbs:// negli script e nelle configurazioni autorizzati senza copiare credenziali. Una corrispondenza indica una possibile dipendenza, non dimostra un uso attivo. Registrate attività, copia effettiva di curl e responsabile. Se SMB scompare dall’elenco dei protocolli dopo la migrazione, è una modifica documentata, non un errore TLS. Concordate con il responsabile applicativo un client SMB supportato o un percorso di trasferimento adeguato; non cambiate protocollo alla cieca. L’accettazione richiede che lo stesso caso di prova autorizzato produca i dati e la gestione degli errori attesi attraverso il nuovo percorso. [3]
  5. Pianificate il passaggio solo dopo l’approvazione. Predisponete pacchetto stabile supportato, backup della configurazione, finestra di manutenzione e procedura di ripristino verificata. Riservate le versioni preliminari a prove facoltative di compatibilità isolate. Modificate prima un’attività rappresentativa e verificate percorso, libreria e risultato nel contesto reale del servizio o container. Estendete il cambiamento solo dopo il collaudo. Un vecchio container o processo persistente può usare ancora la versione precedente: pianificate gli eventuali riavvii.

Diagnosticare senza disattivare i controlli TLS

Se dopo il cambio di pacchetto fallisce la verifica dei certificati, confrontate orologio, nome del server, catena dei certificati, backend TLS e archivio di fiducia. Build diverse possono utilizzare archivi CA diversi. Non nascondete l’errore con --insecure o -k: curl verifica i certificati per impostazione predefinita. [6] Ottenete i certificati CA interni solo attraverso un canale aziendale autorizzato. In caso di autenticazione o reindirizzamenti inattesi, interrompete, conservate un errore depurato dai dati sensibili e coinvolgete il gestore responsabile.

Verifica e ripristino

Il passaggio è concluso quando l’attività di produzione usa in modo dimostrabile l’installazione approvata, supera la matrice e mantiene monitoraggio e gestione degli errori funzionanti. Registrate revisione del pacchetto, momento dell’esecuzione e approvazione. In caso di regressione usate il ripristino documentato del pacchetto o applicazione, senza sostituire singole librerie. Tornare a una versione vulnerabile non è una soluzione duratura: sospendete il flusso se necessario e concordate una misura temporanea con il responsabile della sicurezza. I processi che modificano dati richiedono anche un piano di recupero coerente. Modello di registro, non un test eseguito: «attività; account di servizio/container; percorso completo; revisione del pacchetto/fornitore; dipendenza dal protocollo; contenuto/codice di uscita attesi; risultato; approvazione; ripristino». Senza opzioni adeguate, una risposta di errore HTTP non produce automaticamente un codice di errore curl; controllate separatamente stato, contenuto e codice di uscita. [5]

Data e fonti

Situazione al 16.10.2026. Guida redazionale basata su fonti, non un nostro test di compatibilità o sicurezza. Non si afferma un aumento specifico delle ricerche su curl 8.23.0 o SMB; nessun link affiliato. Verificate separatamente il rilascio e la disponibilità locale dei pacchetti; canali supportati e approvazione restano necessari.