curl 8.23.0 on julkaistu: tarkista käytetty asennus ja SMB-riippuvuudet

curl 8.23.0 julkaistiin 14.10.2026. Päätteen ajantasainen curl ei osoita, että myös liiketoimintasovelluksen libcurl on päivitetty. Skriptejä, kontteja ja toimittajien sovelluksia ylläpitävien pienten IT-tiimien on tunnistettava käytetty kopio, sen toimittaja ja toiminnallisen hyväksynnän kriteerit. Lisäksi on konkreettinen kysymys: tarvitseeko jokin tehtävä edelleen SMB:tä?

Mitä on vahvistettu 14. lokakuuta?

Julkaisutaulukossa on 8.23.0 päivämäärällä 14.10.2026, ja lataussivu tarjoaa sen lähdekoodiarkistot. [1][2] Aiempi kuvaus suunnitellusta julkaisusta on vanhentunut; 8.23.0-rc3 ei ole varsinainen julkaisu. Saatavilla oleva lähdekoodi ei todista paketin saatavuutta omassa jakelukanavassa eikä sisällytetyn kirjaston päivitystä. Pelkkä versionumero ei myöskään osoita jakelupaketin korjaustilannetta, jos korjauksia on siirretty vanhempaan versioon. Muutosloki dokumentoi SMB-tuen poistamisen. [3] Tehtävät, joissa käytetään smb://– tai smbs://-osoitteita, edellyttävät kartoitusta ja toiminnallista tarkistusta ennen siirtymistä. Muutos koskee curlia, ei automaattisesti käyttöjärjestelmän SMB-toimintoa.

Edellytykset ja rajaukset

Tarvitset lukuoikeudet ohjelmistoluetteloon ja ajastettuihin tehtäviin, sovellusvastuuhenkilön sekä erillisen testiympäristön, jossa käytetään muita kuin luottamuksellisia tietoja. Kartoitus ei edellytä ylläpitäjän tekemää asennusta tai järjestelmätiedostojen vaihtamista. Myöhemmät päivitykset tehdään tuetun jakelukanavan kautta. Sovelluksen mukana tuleva libcurl ei välttämättä ole komentorivityökalun käyttämä kirjasto. [4] Älä kopioi vieraita ohjelmatiedostoja tai DLL-kirjastoja sovelluskansioihin.

Viisi vaihetta valmistautumiseen

  1. Kartoita käyttötavat, älä vain versionumeroita. Kirjaa kustakin tärkeästä tehtävästä sovellus, suoritusympäristö, tiedostopolku, paketin lähde, vastuuhenkilö ja liiketoimintatarkoitus. Erottele palvelut, ajastetut tehtävät, CI-suorittimet ja kontit. Omasta päätteestä löytyvä polku ei todista, mitä palvelu käynnistää. Pyydä toimittajan ohjelmistosta komponenttiluettelo tai toimittajan vahvistus; tiedostonimi ei yksin riitä.
  2. Tunnista todella käytetty ohjelmatiedosto. Windowsissa vain lukevan PowerShell-kyselyn Get-Command curl.exe -All avulla voi etsiä suoritettavia tiedostoja; Linuxissa/macOS:ssä command -v curl näyttää nykyisen komentotulkin haun tuloksen. Suorita hyväksytty ja luotettu ohjelma täydellä polulla sekä valitsimella --version. curl --version näyttää muun muassa kirjastot, protokollat ja ominaisuudet. [5] Kirjaa myös TLS-taustakirjasto ja arkkitehtuuri. Tämä ei kartoita muiden prosessien tai erikseen sisällytettyjen kirjastojen versioita. command -v voi palauttaa myös komentotulkin funktion tai aliaksen. Varmista ennen version tarkistusta, että kirjattu polku osoittaa hyväksyttyyn suoritettavaan tiedostoon.
  3. Määritä jokaiselle asennukselle päivitysreitti. Järjestelmäpaketit, konttien pohjalevykuvat, erilliset työkalut ja toimittajien sovellukset tarvitsevat omat vastuuhenkilönsä. Jakelijat voivat siirtää korjauksia vanhempiin versioihin, joten upstream-versionumero ei yksin todista korjaustilannetta. Vertaa julkaisupäivänä toimittajan tiedotetta, pakettirevisiota ja todellista saatavuutta. Älä vaihda libcurl-kirjastoa omin päin toimittajan sovelluksessa. Kirjaa puuttuvat hyväksynnät, vastuuhenkilö ja uusi tarkistuspäivä. [7]
  4. Valmistele pieni toiminnallinen testimatriisi. Valitse testiympäristöön sallittu lataus, tarvittava välityspalvelin- tai tunnistautumistapaus ja hallittu virhevastaus. Määritä etukäteen odotettu HTTP-tila, tuloksen sisältö ja paluukoodi: onnistunut prosessi ei todista liiketoimintatiedon oikeellisuutta. Testaa vain tarvittavat protokollat, älä satunnaisia tuotantokohteita. Salaisuuksia ei saa päätyä komentoriveille tai jaettuihin diagnostiikkalokeihin. Vertaa tuloksia ennen muutosta ja sen jälkeen samalla kokoonpanolla. Uutta versiossa 8.23.0: etsi smb://– ja smbs://-osoitteita hyväksytyistä skripteistä ja asetuksista kopioimatta tunnistetietoja. Osuma on mahdollinen riippuvuus, ei todiste aktiivisesta käytöstä. Kirjaa tehtävä, todellinen curl-kopio ja vastuuhenkilö. Jos SMB puuttuu protokollaluettelosta muutoksen jälkeen, kyse on dokumentoidusta muutoksesta eikä TLS-virheestä. Sovi sovellusvastaavan kanssa tuetusta SMB-asiakasohjelmasta tai toiminnallisesti sopivasta siirtoreitistä; älä vaihda protokollaa sokkona. Hyväksyntä edellyttää, että sama sallittu testitapaus tuottaa odotetut tiedot ja virheenkäsittelyn uuden reitin kautta. [3]
  5. Ajoita muutos vasta hyväksynnän jälkeen. Varaa tuettu vakaa paketti, asetusten varmuuskopio, huoltoikkuna ja todennettu palautusmenettely. Esiversio kuuluu vain valinnaisiin, eristettyihin yhteensopivuustesteihin. Muuta ensin yksi edustava tehtävä ja tarkista sitten polku, kirjasto ja tulos oikeassa palvelu- tai konttiympäristössä. Laajenna vasta toiminnallisen hyväksynnän jälkeen. Vanha kontti tai pitkään käynnissä ollut prosessi voi edelleen käyttää aiempaa versiota; suunnittele tarvittava uudelleenkäynnistys hallitusti.

Vianrajaus poistamatta TLS-tarkistusta käytöstä

Jos varmenteen tarkistus epäonnistuu paketin vaihtamisen jälkeen, vertaa ensin kelloa, palvelimen nimeä, varmenneketjua, TLS-taustakirjastoa ja luottamusvarastoa. Eri koontiversiot voivat käyttää eri CA-varastoja. Älä peitä virhettä valitsimella --insecure tai -k: curl tarkistaa varmenteet oletusarvoisesti. [6] Hanki sisäiset CA-varmenteet vain yrityksen hyväksytystä kanavasta. Keskeytä odottamattoman tunnistautumisen tai uudelleenohjauksen yhteydessä, tallenna arkaluonteisista tiedoista puhdistettu virhekuvaus ja ota yhteys vastuulliseen ylläpitäjään.

Hyväksyntä ja palautus

Muutos on valmis, kun tuotantotehtävä käyttää todennettavasti hyväksyttyä asennusta, läpäisee testimatriisin ja sen valvonta sekä virheenkäsittely toimivat. Kirjaa pakettirevisio, suoritusaika ja hyväksyntä. Jos ilmenee regressio, käytä dokumentoitua paketin tai sovelluksen palautusmenettelyä yksittäisten kirjastojen vaihtamisen sijaan. Haavoittuvaan versioon palaaminen ei ole pysyvä ratkaisu: keskeytä työnkulku tarvittaessa ja sovi määräaikaisesta toimenpiteestä tietoturvavastuuhenkilön kanssa. Tietoja muuttaville prosesseille tarvitaan myös suunnitelma tietojen palauttamiseksi johdonmukaiseen tilaan. Lokimalli, ei tehty testi: ”tehtävä; palvelutili/kontti; täydellinen polku; pakettirevisio/toimittaja; protokollariippuvuus; odotettu sisältö/paluukoodi; tulos; hyväksyntä; palautus”. Ilman sopivia valitsimia HTTP-virhevastaus ei automaattisesti tuota curlin virhekoodia; tarkista tila, sisältö ja paluukoodi erikseen. [5]

Päiväys ja lähteet

Tilanne 16.10.2026. Lähteisiin perustuva toimituksellinen ohje, ei oma yhteensopivuus- tai tietoturvatesti. Emme väitä curl 8.23.0:aan tai SMB:hen liittyvien hakujen erityistä kasvua; ei kumppanuuslinkkejä. Tarkista projektin julkaisu ja paketin paikallinen saatavuus erikseen; tuettu jakelukanava ja hyväksyntä ovat edelleen tarpeen.