curl 8.23.0 już dostępny: sprawdź rzeczywistą instalację i zależności od SMB

curl 8.23.0 wydano 14.10.2026. Aktualny curl w terminalu nie dowodzi, że zaktualizowano też bibliotekę libcurl aplikacji biznesowej. Małe zespoły IT utrzymujące skrypty, kontenery i aplikacje dostawców muszą ustalić używaną kopię, jej dostawcę i kryteria odbioru funkcjonalnego. Jest też konkretne pytanie: czy jakieś zadanie nadal wymaga SMB?

Co potwierdzono 14 października

Tabela wydań podaje 8.23.0 z datą 14.10.2026, a strona pobierania udostępnia archiwa źródłowe. [1][2] Wcześniejsze sformułowanie o planowanym wydaniu jest nieaktualne; 8.23.0-rc3 nie jest wydaniem regularnym. Dostępne źródła nie dowodzą dostępności w kanale pakietów ani aktualizacji wbudowanej biblioteki. Sam numer wersji nie wystarcza również do oceny poprawek przeniesionych do pakietu dystrybucji. Dziennik zmian dokumentuje usunięcie obsługi SMB. [3] Zadania z smb:// lub smbs:// wymagają więc inwentaryzacji i sprawdzenia funkcjonalnego przed migracją. Dotyczy to curl, nie automatycznie obsługi SMB przez system operacyjny.

Wymagania i ograniczenia

Potrzebujesz dostępu do odczytu inwentarza oprogramowania i zaplanowanych zadań, opiekuna aplikacji oraz osobnego środowiska testowego z danymi niepoufnymi. Inwentaryzacja nie wymaga instalacji administracyjnej ani podmiany plików systemowych. Późniejsze aktualizacje muszą korzystać ze wspieranego kanału. Biblioteka libcurl dołączona do aplikacji nie musi być biblioteką używaną przez narzędzie wiersza poleceń. [4] Nie kopiuj obcych plików wykonywalnych ani DLL do katalogów aplikacji.

Pięć kroków przygotowania

  1. Zinwentaryzuj zastosowania, nie tylko wersje. Dla każdego ważnego zadania zapisz aplikację, kontekst uruchomienia, ścieżkę, źródło pakietu, właściciela i cel biznesowy. Oddzielnie uwzględnij usługi, zadania harmonogramu, wykonawców CI i kontenery. Ścieżka znaleziona w osobistym terminalu nie potwierdza tego, co uruchamia usługa. W przypadku aplikacji dostawcy poproś o wykaz komponentów lub potwierdzenie wsparcia; sama nazwa pliku nie wystarcza.
  2. Ustal faktycznie używany program. W Windows zapytanie PowerShell tylko do odczytu Get-Command curl.exe -All pomaga znaleźć pliki wykonywalne; w Linux/macOS command -v curl pokazuje wynik wyszukiwania w bieżącej powłoce. Uruchom zatwierdzony, zaufany plik przez pełną ścieżkę z --version. curl --version podaje informacje o bibliotekach, protokołach i funkcjach. [5] Zapisz także backend TLS i architekturę. Nie jest to inwentaryzacja innych procesów ani osobno osadzonych bibliotek. command -v może również zwrócić funkcję powłoki lub alias. Przed sprawdzeniem wersji upewnij się, że zapisana ścieżka wskazuje zatwierdzony plik wykonywalny.
  3. Przypisz każdej instalacji drogę aktualizacji. Pakiety systemowe, obrazy bazowe kontenerów, samodzielne narzędzia i aplikacje dostawców wymagają własnych opiekunów. Dystrybutorzy mogą przenosić poprawki do starszych wersji, więc numer upstream sam nie rozstrzyga stanu zabezpieczeń. W dniu wydania porównaj komunikat dostawcy, rewizję pakietu i rzeczywistą dostępność. Nie podmieniaj samowolnie libcurl w aplikacji dostawcy. Brakujące zgody zapisz wraz z odpowiedzialną osobą i terminem przeglądu. [7]
  4. Przygotuj niewielką macierz testów funkcjonalnych. Wybierz dozwolone pobranie, potrzebny przypadek proxy/uwierzytelnienia i kontrolowaną odpowiedź błędu w środowisku testowym. Z góry określ status HTTP, oczekiwaną treść i kod wyjścia: poprawne zakończenie procesu nie dowodzi poprawności danych biznesowych. Testuj tylko potrzebne protokoły, bez odpytywania przypadkowych celów produkcyjnych. Sekrety nie mogą trafiać do poleceń ani współdzielonych logów. Porównaj wyniki przed zmianą i po niej przy tej samej konfiguracji. Nowość w 8.23.0: sprawdź zatwierdzone skrypty i konfiguracje pod kątem smb:// oraz smbs://, nie kopiując danych uwierzytelniających. Trafienie wskazuje możliwą zależność, nie dowodzi aktywnego użycia. Zapisz zadanie, rzeczywistą kopię curl i osobę odpowiedzialną. Brak SMB na liście protokołów po zmianie jest udokumentowaną zmianą tego wydania, nie błędem TLS. Uzgodnij z opiekunem aplikacji wspierany klient SMB albo funkcjonalnie odpowiednią drogę przesyłania; nie zmieniaj protokołu w ciemno. Odbiór wymaga, aby ten sam dozwolony przypadek testowy dawał oczekiwane dane i obsługę błędów nową drogą. [3]
  5. Zaplanuj zmianę dopiero po zatwierdzeniu. Przygotuj wspierany stabilny pakiet, kopię konfiguracji, okno serwisowe i sprawdzoną drogę powrotu. Wersję wstępną pozostaw wyłącznie do opcjonalnych, odizolowanych testów zgodności. Najpierw zmień jedno reprezentatywne zadanie, a następnie sprawdź ścieżkę, bibliotekę i wynik w rzeczywistym kontekście usługi lub kontenera. Rozszerz wdrożenie dopiero po odbiorze. Stary kontener lub długotrwały proces może nadal używać poprzedniej wersji; zaplanuj potrzebny restart.

Diagnostyka bez wyłączania weryfikacji TLS

Jeśli po zmianie pakietu zawiedzie weryfikacja certyfikatów, porównaj zegar, nazwę hosta, łańcuch certyfikatów, backend TLS i magazyn zaufania. Różne kompilacje mogą korzystać z różnych magazynów CA. Nie uciszaj błędu przez --insecure lub -k: curl domyślnie sprawdza certyfikaty. [6] Wewnętrzne certyfikaty CA pozyskuj tylko zatwierdzonym kanałem firmowym. Przy nieoczekiwanym uwierzytelnieniu lub przekierowaniu przerwij, zachowaj oczyszczony zapis błędu i zaangażuj odpowiedzialnego administratora.

Odbiór i wycofanie zmiany

Zmiana jest zakończona, gdy zadanie produkcyjne w sposób udokumentowany korzysta z zatwierdzonej instalacji, przechodzi testy i ma działający monitoring oraz obsługę błędów. Zapisz rewizję pakietu, czas wykonania i odbiór. Przy regresji użyj udokumentowanego wycofania pakietu lub aplikacji zamiast podmieniać pojedyncze biblioteki. Powrót do podatnej wersji nie jest trwałym rozwiązaniem: w razie potrzeby wstrzymaj proces i uzgodnij czasowy środek z osobą odpowiedzialną za bezpieczeństwo. Procesy zmieniające dane wymagają również planu ich spójnego odtworzenia. Szablon zapisu, nie wykonany test: „zadanie; konto usługi/kontener; pełna ścieżka; rewizja pakietu/dostawca; zależność od protokołu; oczekiwana treść/kod wyjścia; wynik; zgoda; wycofanie”. Bez odpowiednich opcji odpowiedź błędu HTTP nie powoduje automatycznie kodu błędu curl; sprawdzaj osobno status, treść i kod wyjścia. [5]

Data i źródła

Stan na 16.10.2026. Poradnik redakcyjny oparty na źródłach, bez własnego testu zgodności lub bezpieczeństwa curl. Nie twierdzimy, że wystąpił szczególny wzrost wyszukiwań curl 8.23.0 lub SMB; bez linków afiliacyjnych. Osobno sprawdź wydanie projektu i lokalną dostępność pakietu; wspierany kanał i zgoda nadal są wymagane.