curl 8.23.0 er utgitt: kontroller faktisk installasjon og SMB-avhengigheter

curl 8.23.0 ble utgitt 14. oktober 2026. En oppdatert curl i terminalen beviser ikke at libcurl i en forretningsapplikasjon også er oppdatert. Små IT-team med skript, containere og leverandørapplikasjoner må identifisere den brukte kopien, leverandøren og kriteriene for funksjonell godkjenning. Et konkret spørsmål kommer i tillegg: krever en jobb fortsatt SMB?

Hva er bekreftet 14. oktober?

Utgivelsestabellen viser 8.23.0 datert 14. oktober 2026, og nedlastingssiden tilbyr kildearkivene. [1][2] Den tidligere omtalen av en planlagt utgivelse er dermed utdatert; 8.23.0-rc3 er ikke den ordinære utgivelsen. Tilgjengelig kildekode beviser verken tilgjengelighet i pakkekanalen eller oppdatering av et innebygd bibliotek. Versjonsnummeret alene fastslår heller ikke oppdateringsstatus for en distribusjonspakke med tilbakeførte rettinger. Endringsloggen dokumenterer at SMB-støtte er fjernet. [3] Jobber med smb:// eller smbs:// krever derfor målrettet kartlegging og funksjonell kontroll før migrering. Dette gjelder curl, ikke automatisk operativsystemets SMB-funksjon.

Forutsetninger og begrensninger

Dere trenger lesetilgang til programvareoversikten og planlagte oppgaver, en applikasjonsansvarlig og et separat testmiljø med ikke-konfidensielle data. Kartleggingen krever ingen administratorinstallasjon eller utskifting av systemfiler. Senere oppdateringer må følge den støttede distribusjonskanalen. En medfølgende libcurl er ikke nødvendigvis biblioteket som kommandolinjeverktøyet bruker. [4] Ikke kopier fremmede programfiler eller DLL-er inn i applikasjonsmapper.

Fem trinn for en grundig forberedelse

  1. Kartlegg bruken, ikke bare versjonsnumrene. Registrer applikasjon, kjørekontekst, filbane, pakkekilde, ansvarlig og forretningsformål for hver viktig jobb. Skill mellom tjenester, planlagte oppgaver, CI-kjørere og containere. En filbane fra din personlige terminal beviser ikke hva en tjeneste starter. Be om komponentoversikt eller leverandørbekreftelse for tredjepartsprogramvare; et filnavn er ikke tilstrekkelig.
  2. Identifiser programfilen som faktisk brukes. I Windows hjelper PowerShell-spørringen Get-Command curl.exe -All med å finne kjørbare filer; i Linux/macOS viser command -v curl oppslaget i gjeldende skall. Kjør den godkjente, betrodde filen med full filbane og --version. curl --version viser blant annet biblioteker, protokoller og funksjoner. [5] Registrer også TLS-backend og arkitektur. Dette kartlegger ikke andre prosesser eller separat innebygde biblioteker. command -v kan også returnere en skallfunksjon eller et alias. Kontroller før versjonsspørringen at den registrerte banen faktisk peker på den godkjente programfilen.
  3. Fastsett oppdateringsveien for hver installasjon. Systempakker, basisavbildninger for containere, selvstendige verktøy og leverandørapplikasjoner trenger hver sin ansvarlige. Distributører kan tilbakeføre rettinger til eldre versjoner; upstream-nummeret alene er derfor ikke et endelig bevis på oppdateringsstatus. Sammenlign leverandørvarsel, pakkerevisjon og faktisk tilgjengelighet på utgivelsesdagen. Ikke bytt ut libcurl på egen hånd i en uendret leverandørapplikasjon. Registrer manglende godkjenninger med ansvarlig og dato for ny vurdering. [7]
  4. Lag en liten matrise med funksjonelle tester. Velg en godkjent nedlasting, et nødvendig proxy-/autentiseringstilfelle og en kontrollert feilrespons i testmiljøet. Definer forventet HTTP-status, resultatinnhold og avslutningskode på forhånd: en vellykket prosess beviser ikke korrekte forretningsdata. Test bare nødvendige protokoller, ikke vilkårlige produksjonsadresser. Hemmeligheter hører ikke hjemme på kommandolinjen eller i delte diagnoselogger. Sammenlign før og etter med samme konfigurasjon. Nytt i 8.23.0: søk etter smb:// og smbs:// i godkjente skript og konfigurasjoner uten å kopiere påloggingsopplysninger. Et treff er en mulig avhengighet, ikke bevis på aktiv bruk. Registrer jobben, faktisk curl-kopi og ansvarlig. Hvis SMB forsvinner fra protokollisten etter endringen, er det en dokumentert endring, ikke en TLS-feil. Avtal en støttet SMB-klient eller en funksjonelt egnet overføringsvei med applikasjonsansvarlig; ikke bytt protokoll blindt. Godkjenning krever at samme tillatte testtilfelle gir forventede data og feilhåndtering gjennom den nye løsningen. [3]
  5. Planlegg endringen først etter godkjenning. Klargjør en støttet stabil pakke, konfigurasjonsbackup, vedlikeholdsvindu og en verifisert vei tilbake. En forhåndsversjon er bare for valgfrie, isolerte kompatibilitetstester. Endre først én representativ jobb, og kontroller deretter filbane, bibliotek og resultat i den faktiske tjeneste- eller containerkonteksten. Utvid først etter faglig godkjenning. En gammel container eller langvarig prosess kan fortsatt bruke forrige versjon; planlegg en nødvendig omstart kontrollert.

Feilsøk uten å slå av TLS-kontroll

Hvis sertifikatkontrollen feiler etter et pakkebytte, sammenlign først klokke, vertsnavn, sertifikatkjede, TLS-backend og tillitslager. Ulike bygg kan bruke forskjellige CA-lagre. Ikke skjul feilen med --insecure eller -k: curl verifiserer sertifikater som standard. [6] Hent interne CA-sertifikater bare via virksomhetens autoriserte kanal. Stopp ved uventet autentisering eller omdirigering, lagre en renset feilbeskrivelse og involver driftsansvarlig.

Godkjenning og tilbakeføring

Endringen er fullført når produksjonsjobben dokumenterbart bruker den godkjente installasjonen, består testmatrisen og har fungerende overvåking og feilhåndtering. Registrer pakkerevisjon, kjøretidspunkt og godkjenning. Ved regresjon brukes dokumentert tilbakeføring av pakke eller applikasjon, ikke utskifting av enkeltbiblioteker. En sårbar tidligere versjon er ingen varig løsning: sett om nødvendig arbeidsflyten på pause, og avtal et tidsbegrenset tiltak med sikkerhetsansvarlig. Prosesser som endrer data trenger også en plan for konsistent gjenoppretting av dataene. Loggmal, ikke en utført test: «jobb; tjenestekonto/container; full filbane; pakkerevisjon/leverandør; protokollavhengighet; forventet innhold/avslutningskode; resultat; godkjenning; tilbakeføring». Uten egnede valg gir et HTTP-feilsvar ikke automatisk en curl-feilkode; kontroller status, innhold og avslutningskode hver for seg. [5]

Dato og kilder

Status: 16.10.2026. Kildebasert redaksjonell veiledning, ikke vår egen kompatibilitets- eller sikkerhetstest. Det hevdes ingen særskilt økning i søk etter curl 8.23.0 eller SMB; ingen affiliatelenker. Kontroller prosjektutgivelsen og lokal pakketilgjengelighet hver for seg; støttet kanal og godkjenning er fortsatt nødvendig.