curl 8.23.0 er udgivet: kontrollér den faktiske installation og SMB-afhængigheder

curl 8.23.0 blev udgivet 14. oktober 2026. En opdateret curl i terminalen beviser ikke, at libcurl i en forretningsapplikation også er opdateret. Små it-teams med scripts, containere og leverandørapplikationer skal identificere den anvendte kopi, leverandøren og kriterierne for funktionel godkendelse. Der er også et konkret spørgsmål: kræver et job stadig SMB?

Hvad er bekræftet den 14. oktober?

Udgivelsestabellen viser 8.23.0 dateret 14. oktober 2026, og downloadsiden tilbyder kildearkiverne. [1][2] Den tidligere beskrivelse af en planlagt udgivelse er dermed forældet; 8.23.0-rc3 er ikke den almindelige udgivelse. Tilgængelig kildekode beviser hverken tilgængelighed i jeres pakkekanal eller en opdateret indbygget bibliotekskopi. Versionsnummeret alene fastslår heller ikke patchstatus for en distributionspakke med tilbageførte rettelser. Ændringsloggen dokumenterer, at SMB-understøttelse er fjernet. [3] Job med smb:// eller smbs:// kræver derfor målrettet registrering og funktionel kontrol før migrering. Det gælder curl, ikke automatisk operativsystemets SMB-funktion.

Forudsætninger og begrænsninger

I skal bruge læseadgang til softwareoversigten og planlagte opgaver, en applikationsansvarlig og et separat testmiljø med ikke-fortrolige data. Registreringen kræver ingen administratorinstallation eller udskiftning af systemfiler. Senere opdateringer skal følge den understøttede distributionskanal. En medfølgende libcurl er ikke nødvendigvis biblioteket bag kommandolinjeværktøjet. [4] Kopiér ikke fremmede programmer eller DLL-filer ind i applikationsmapper.

Fem trin til en solid forberedelse

  1. Registrér anvendelsen, ikke kun versionsnummeret. Notér applikation, kørselskontekst, sti, pakkekilde, ansvarlig og forretningsformål for hvert vigtigt job. Medtag tjenester, planlagte opgaver, CI-runners og containere hver for sig. En sti fra den personlige terminal beviser ikke, hvad en tjeneste starter. Bed om komponentoversigt eller leverandørbekræftelse for tredjepartssoftware; et filnavn er ikke nok.
  2. Identificér den faktisk anvendte programfil. I Windows hjælper PowerShell-forespørgslen Get-Command curl.exe -All med at finde eksekverbare filer uden at ændre noget; i Linux/macOS viser command -v curl den aktuelle shells opslag. Kør den godkendte, betroede fil via dens fulde sti med --version. curl --version viser blandt andet biblioteker, protokoller og funktioner. [5] Registrér også TLS-backend og arkitektur. Dette registrerer ikke andre processer eller særskilt indbyggede biblioteker. command -v kan også returnere en shellfunktion eller et alias. Kontrollér før versionsforespørgslen, at den registrerede sti faktisk peger på den godkendte programfil.
  3. Fastlæg opdateringsvejen for hver installation. Systempakker, containerbasisbilleder, selvstændige værktøjer og leverandørapplikationer skal have hver sin ansvarlige. Distributører kan tilbageføre rettelser til ældre versioner; upstream-nummeret alene dokumenterer derfor ikke patchstatus. Sammenlign leverandørmeddelelse, pakkerevision og faktisk tilgængelighed på udgivelsesdagen. Udskift ikke selv libcurl i en uændret leverandørapplikation. Registrér manglende godkendelser med ansvarlig og dato for opfølgning. [7]
  4. Forbered en lille matrix med funktionelle tests. Vælg en tilladt download, et nødvendigt proxy-/loginforløb og et kontrolleret fejlsvar i testmiljøet. Fastlæg forventet HTTP-status, resultatindhold og afslutningskode på forhånd: en vellykket proces beviser ikke korrekte forretningsdata. Test kun nødvendige protokoller, ikke vilkårlige produktionsadresser. Hemmeligheder må ikke stå i kommandolinjer eller delte diagnoselogfiler. Sammenlign før og efter med samme konfiguration. Nyt i 8.23.0: søg efter smb:// og smbs:// i godkendte scripts og konfigurationer uden at kopiere legitimationsoplysninger. Et fund er en mulig afhængighed, ikke bevis på aktiv brug. Registrér jobbet, den faktiske curl-kopi og den ansvarlige. Hvis SMB forsvinder fra protokollisten efter ændringen, er det en dokumenteret ændring, ikke en TLS-fejl. Aftal en understøttet SMB-klient eller en funktionelt passende overførselsvej med applikationsansvarlig; skift ikke protokol blindt. Godkendelse kræver, at samme tilladte testtilfælde giver forventede data og fejlhåndtering via den nye vej. [3]
  5. Planlæg først ændringen efter godkendelse. Hav en understøttet stabil pakke, konfigurationsbackup, vedligeholdelsesvindue og verificeret tilbagerulning klar. En forhåndsversion er kun til valgfrie, isolerede kompatibilitetstests. Skift først ét repræsentativt job, og kontrollér derefter sti, bibliotek og resultat i den faktiske tjeneste- eller containerkontekst. Udvid først efter faglig godkendelse. En gammel container eller langvarig proces kan stadig bruge den tidligere version; planlæg en nødvendig genstart kontrolleret.

Fejlsøg uden at slå TLS-kontrol fra

Hvis certifikatkontrollen fejler efter pakkeskift, sammenlign først ur, værtsnavn, certifikatkæde, TLS-backend og tillidslager. Forskellige builds kan bruge forskellige CA-lagre. Skjul ikke fejlen med --insecure eller -k: curl kontrollerer certifikater som standard. [6] Hent interne CA-certifikater kun gennem virksomhedens godkendte kanal. Stop ved uventet autentificering eller omdirigering, gem en renset fejlbeskrivelse og inddrag den ansvarlige driftsmedarbejder.

Godkendelse og tilbagerulning

Ændringen er afsluttet, når produktionsjobbet dokumenterbart bruger den godkendte installation, består testmatricen og har fungerende overvågning og fejlhåndtering. Registrér pakkerevision, kørselstidspunkt og godkendelse. Ved regression bruges den dokumenterede tilbagerulning af pakke eller applikation, ikke udskiftning af enkelte biblioteker. En sårbar tidligere version er ingen varig løsning: sæt om nødvendigt arbejdsgangen på pause, og aftal en tidsbegrænset foranstaltning med den sikkerhedsansvarlige. Processer, der ændrer data, kræver også en plan for konsistent datagendannelse. Logskabelon, ikke en udført test: »job; tjenestekonto/container; fuld sti; pakkerevision/leverandør; protokolafhængighed; forventet indhold/afslutningskode; resultat; godkendelse; tilbagerulning«. Uden passende indstillinger giver et HTTP-fejlsvar ikke automatisk en curl-fejlkode; kontrollér status, indhold og afslutningskode hver for sig. [5]

Dato og kilder

Status: 16.10.2026. Kildebaseret redaktionel vejledning, ikke vores egen kompatibilitets- eller sikkerhedstest. Der påstås ingen særlig stigning i søgninger om curl 8.23.0 eller SMB; ingen affiliatelinks. Kontrollér projektets udgivelse og lokal pakketilgængelighed hver for sig; understøttet kanal og godkendelse er fortsat nødvendige.