Jak poprawnie aktualizować bezpieczeństwo w FreeBSD

Jak FreeBSD obsługuje aktualizacje bezpieczeństwa

FreeBSD obsługuje aktualizacje bezpieczeństwa za pomocą dwóch oddzielnych narzędzi, ponieważ serwer FreeBSD składa się z dwóch odrębnych elementów. System podstawowy, czyli kernel oraz środowisko użytkownika dostarczone wraz z wydaniem, jest łatany za pomocą freebsd-update. Wszystko, co zostało zainstalowane dodatkowo, stanowi pakiet, a pakiety są łatane za pomocą pkg. Uruchomienie jednego narzędzia z pominięciem drugiego sprawia, że połowa maszyny pozostaje niezałatana, a system nie wyświetli żadnego powiadomienia w tej sprawie.

SSD Nodes nie oferuje obrazów FreeBSD. Nasze plany obejmują systemy Linux. Ten wpis powstał mimo to, ponieważ grupy odbiorców całkowicie się pokrywają: osoby zarządzające naszymi serwerami Ubuntu i Debian często używają FreeBSD na firewallach lub na pojedynczych maszynach przejętych w spadku. Rozdzielony model aktualizacji jest elementem, który często zaskakuje administratorów systemów Linux, dlatego warto go opisać. Każde polecenie, format biuletynu bezpieczeństwa oraz data wsparcia technicznego poniżej zostały zweryfikowane zgodnie ze stroną bezpieczeństwa FreeBSD oraz stronami podręcznika systemowego projektu w październiku 2026 roku.

Jedna uwaga przed przejściem do poleceń. FreeBSD nie instaluje sudo w systemie podstawowym. Wszystkie poniższe operacje wymagają uprawnień root. Należy użyć su - lub najpierw zainstalować sudo bądź doas z pakietów.

System bazowy i pakiety to odrębne światy

W systemie Ubuntu, apt zarządza całą maszyną. Jądro, openssl, nginx oraz własne narzędzia użytkownika są dostarczane jako pliki .deb przez jedno narzędzie, a apt upgrade aktualizuje je wszystkie jednocześnie.

FreeBSD dzieli ten proces na dwie części. W klasycznej instalacji system bazowy jest dostarczany w zestawach dystrybucyjnych i jest łatany wyłącznie przez freebsd-update. freebsd-version -u raportuje jeden poziom poprawek dla zainstalowanego środowiska użytkownika, na przykład 15.1-RELEASE-p3, co obejmuje bibliotekę C, sshd oraz kopię OpenSSL w /usr/lib. Jądro posiada własny poziom poprawek, raportowany przez freebsd-version -k, dlatego obie wartości mogą się różnić. Żaden z tych elementów nie pochodzi z pkg. Cała reszta znajduje się w /usr/local, jest dostarczana jako pakiety binarne zbudowane z drzewa ports i posiada własną wersję.

Instalator 15.x oferuje również drugą ścieżkę. Rozdział podręcznika dotyczący instalacji wymienia zestawy dystrybucyjne (metoda klasyczna) obok pakietów (wersja poglądowa), często nazywanych pkgbase. Instalują one system bazowy jako zestaw pojedynczych pakietów z repozytorium FreeBSD-base, dzięki czemu pkg upgrade może aktualizować system bazowy i oprogramowanie firm trzecich jednocześnie. Podręcznik przewiduje, że pkgbase stanie się domyślnym rozwiązaniem w FreeBSD 16.0 i zaleca zestawy dystrybucyjne jako konserwatywną ścieżkę aktualizacji w cyklu życia 15.x, szczególnie w środowiskach produkcyjnych. Reszta tego wpisu opiera się na modelu zestawów dystrybucyjnych.

Dlatego jedna maszyna może zawierać dwie kopie OpenSSL: kopię bazową w /usr/lib, łataną tylko przez freebsd-update, oraz kopię pakietową w /usr/local/lib, łataną tylko przez pkg. To, której kopii użyje program, zależy od tego, z którą został skonsolidowany (linked against), a oprogramowanie instalowane z pakietów zazwyczaj korzysta z kopii pakietowej. Łatanie jednej nie wpływa na drugą.

Trzy polecenia pozwalają określić stan systemu:

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u wyświetla poziom poprawek zainstalowanego środowiska użytkownika. freebsd-version -k wyświetla poziom poprawek zainstalowanego jądra, a freebsd-version(1) wyjaśnia, dlaczego nie jest on tożsamy z uname: "jeśli zainstalowano nowe jądro, ale system nie został jeszcze zrestartowany, freebsd-version wyświetli wersję i poziom poprawek nowego jądra". uname -r wyświetla aktualnie uruchomione jądro. Istnieje również freebsd-version -r, które wyświetla uruchomione jądro, ale jest "odporne na zmienne środowiskowe", co ma znaczenie wewnątrz jaila, gdzie UNAME_r jest często ustawione na inną wartość.

Biuletyny bezpieczeństwa i powiadomienia o erratach

Zespół ds. bezpieczeństwa FreeBSD wydaje dwa rodzaje powiadomień, które pełnią odmienne funkcje.

Biuletyn bezpieczeństwa (Security Advisory) dotyczy luki w zabezpieczeniach systemu bazowego. Identyfikator ma postać FreeBSD-SA-26:55.elf: litery SA, dwucyfrowy rok, kolejny numer w danym roku oraz nazwa dotkniętego komponentu. Biuletyny FreeBSD-SA-26:52.if_wg oraz FreeBSD-SA-26:50.kqueue zostały opublikowane 2026-07-29. Pełna lista znajduje się na stronie biuletynów FreeBSD.

Powiadomienie o erracie (Errata Notice) dotyczy problemów z poprawnością lub stabilnością, które wymagają wdrożenia w gałęzi wydania, ale nie mają wpływu na bezpieczeństwo. Format jest identyczny, z tą różnicą, że zamiast SA stosuje się EN: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Klasycznym przykładem jest aktualizacja danych stref czasowych. Nieaktualne dane stref czasowych nie stanowią wektora ataku, jednak powodują błędne znaczniki czasu do momentu zastosowania poprawki. Erraty są wymienione na stronie powiadomień o erratach FreeBSD.

Oba rodzaje powiadomień są podpisane kluczem PGP (Pretty Good Privacy) oficera ds. bezpieczeństwa i archiwizowane pod adresem security.FreeBSD.org. Oba są również dostarczane do systemu za pomocą freebsd-update.

W tym miejscu często pojawiają się nieporozumienia u administratorów systemów Linux. Żaden z tych rodzajów powiadomień nie dotyczy pakietów. Strona dotycząca bezpieczeństwa jasno to określa: problemy w kolekcji FreeBSD Ports "są opisywane oddzielnie w dokumencie FreeBSD VuXML". Zdalna luka w pakiecie nginx nigdy nie otrzyma numeru SA. Jeśli monitorowany jest wyłącznie kanał biuletynów, informacje o takich zagrożeniach nie zostaną odebrane.

Jak otrzymywać informacje o aktualizacjach bezpieczeństwa FreeBSD?

Listą, do której należy dołączyć, jest freebsd-security-notifications. Jest ona moderowana i generuje niewielki ruch, a publikowane są na niej bezpośrednio powiadomienia o poprawkach (advisories) oraz erraty. Subskrypcji można dokonać pod adresem lists.freebsd.org.

freebsd-announce również jest moderowana i zawiera powiadomienia o poprawkach wraz z ogłoszeniami o wydaniach, więc jest odpowiednia, jeśli preferuje się jedną listę dla wszystkich informacji. freebsd-security to lista dyskusyjna. Jej lektura jest przydatna, jednak nie jest to miejsce, w którym uzyskuje się informacje o konieczności instalacji poprawek.

Wszystkie te listy dotyczą wyłącznie systemu bazowego. Informacje o podatnościach pakietów nie są przesyłane pocztą elektroniczną. Należy je sprawdzać poprzez wykonanie odpowiedniego polecenia.

pkg audit oraz powiązana z nim baza danych

VuXML, czyli Vulnerabilities and Exposures Markup Language, to prowadzony przez projekt FreeBSD rejestr problemów bezpieczeństwa w portach i pakietach. Każdy wpis zawiera nazwę pakietu, zakresy wersji podatnych na zagrożenia, identyfikatory CVE (Common Vulnerabilities and Exposures) oraz krótki opis. Cały zbiór można przeglądać w indeksie VuXML, sortując według pakietu, numeru CVE lub daty.

pkg audit to narzędzie, które odczytuje te dane:

pkg audit -F

-F pobiera świeżą kopię bazy danych przed rozpoczęciem sprawdzania. Należy używać tej flagi za każdym razem. Bez -F porównanie odbywa się względem kopii znajdującej się lokalnie na maszynie, która może być nieaktualna od miesięcy, przez co wynik „czysty” jest bezwartościowy. Polecenie porównuje wersję każdego zainstalowanego pakietu z każdym wpisem w VuXML, wyświetla dopasowania wraz z numerami CVE oraz linkiem do strony VuXML, a na końcu podaje podsumowanie liczby znalezionych problemów w zainstalowanych pakietach.

Warto znać jeszcze dwie flagi opisane w pkg-audit(8). pkg audit -r dodatkowo „wyświetla pakiety zależne od podatnych pakietów, które tym samym również mogą być zagrożone” – w ten sposób można ustalić, że podatna biblioteka jest istotna, ponieważ korzysta z niej sześć zainstalowanych aplikacji. pkg audit -R wyświetla wynik w formacie JSON lub innym formacie maszynowym, co jest przydatne przy integracji z systemami monitoringu.

Pakiet pkg instaluje skrypt okresowy w /usr/local/etc/periodic/security/410.pkg-audit. Jest on uruchamiany w ramach codziennego sprawdzania bezpieczeństwa i wysyła wynik pocztą do użytkownika root. Skrypt jest domyślnie włączony. Aby ustawić go jawnie, należy dodać linię do /etc/periodic.conf:

security_status_pkgaudit_enable="YES"

Ta codzienna wiadomość e-mail jest najbliższym odpowiednikiem mechanizmu unattended-upgrades znanego z Ubuntu w systemie FreeBSD, przy czym różnica stanowi istotę podejścia: unattended-upgrades instaluje poprawki automatycznie w nocy, a pkg audit jedynie informuje o konieczności ich wdrożenia. pkg audit generuje raporty. Nigdy nie nakłada poprawek. W standardowej instalacji FreeBSD żaden mechanizm nie instaluje aktualizacji bezpieczeństwa bez ingerencji administratora.

Naprawa podatnego pakietu

pkg update
pkg upgrade

W repozytoriach pakietów FreeBSD nie istnieje wydzielony kanał wyłącznie dla poprawek bezpieczeństwa. System Ubuntu pozwala na pobieranie aktualizacji wyłącznie z noble-security, pozostawiając pozostałe pakiety w dotychczasowych wersjach. FreeBSD nie posiada odpowiednika tego rozwiązania, dlatego naprawa jednego podatnego pakietu wiąże się z przyjęciem wersji oferowanej obecnie przez repozytorium wraz ze wszystkimi powiązanymi zależnościami. Planuj aktualizacje pakietów jako zaplanowaną zmianę, a nie jako zadanie wykonywane w tle.

Szybkość otrzymania poprawki zależy od wybranej gałęzi repozytorium. Domyślnie stosowana jest gałąź quarterly, która według podręcznika zapewnia „bardziej przewidywalne i stabilne środowisko” poprzez przyjmowanie wyłącznie aktualizacji niezawierających nowych funkcji. Gałąź latest zawiera najnowsze wersje wszystkich pakietów. Jeśli zatem pkg audit -F zgłasza podatność pakietu, a pkg upgrade informuje, że brak dostępnych aktualizacji, oznacza to, że poprawka nie trafiła jeszcze do używanej gałęzi. Jest to mechanizm często prowadzący do nieporozumień.

Aby przełączyć maszynę na gałąź latest, skopiuj plik repozytorium dostarczony z systemem i edytuj kopię:

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Zmień quarterly na latest w linii url wewnątrz kopii, a następnie uruchom pkg update -f, aby pobrać nowy katalog. Skopiuj plik zamiast wpisywać nazwę repozytorium z pamięci: nazwa wewnątrz /etc/pkg/FreeBSD.conf jest tą, której faktycznie używa system, a plik w lokalizacji /usr/local/etc/pkg/repos nadpisuje tylko to repozytorium, którego nazwa jest identyczna.

Stosowanie poprawek systemu podstawowego

freebsd-update fetch
freebsd-update install

fetch pobiera poprawki dla bieżącego wydania i wyświetla listę plików, które zostaną zmodyfikowane. Jeśli nie ma żadnych zadań do wykonania, narzędzie wyświetla No updates needed to update system to 15.1-RELEASE-p3. i kończy działanie. Jeśli dostępne są poprawki, proces kończy się komunikatem informującym o konieczności uruchomienia polecenia instalacji. Żadne zmiany nie zostaną wprowadzone, dopóki nie zostanie uruchomione freebsd-update install, dlatego fetch można bezpiecznie wywoływać w dowolnym momencie.

freebsd-update(8) dostarcza aktualizacje binarne dla wersji ALPHA, BETA, RC oraz RELEASE, ale nie dla PRERELEASE, STABLE ani CURRENT. W przypadku korzystania z stable/15 kompilacja odbywa się ze źródeł, więc to narzędzie nie ma zastosowania.

Pobieranie można zautomatyzować, pozostawiając instalację jako proces ręczny. Wiersz dla /etc/crontab z podręcznika systemowego:

@daily                                  root    freebsd-update cron

freebsd-update cron odczekuje losowy czas od 1 do 3600 sekund, a następnie pobiera aktualizacje w taki sam sposób jak fetch i wysyła wiadomość e-mail do użytkownika root, gdy oczekują one na instalację. Losowe opóźnienie zapobiega sytuacji, w której wszystkie maszyny z FreeBSD w Internecie obciążają serwery lustrzane w tej samej sekundzie.

Dwa elementy w wynikach działania polecenia często wprowadzają użytkowników w błąd. src component not installed, skipped jest normalnym zjawiskiem na serwerze bez drzewa źródeł i nie stanowi błędu. Zestaw komponentów jest kontrolowany przez linię Components w pliku /etc/freebsd-update.conf, a dostępne opcje to src, world oraz kernel.

Jeśli instalacja przebiegnie nieprawidłowo, freebsd-update rollback usuwa ostatnio zainstalowane poprawki. W przypadku systemu z rootem na ZFS można postąpić lepiej, tworząc najpierw środowisko rozruchowe (boot environment):

bectl create pre-patch
freebsd-update fetch install

Jeśli poprawiony system nie uruchamia się, należy wybrać stare środowisko rozruchowe z menu programu ładującego, co przywróci system do stanu początkowego. Ta możliwość wycofania zmian jest jednym z praktycznych powodów używania ZFS jako systemu plików dla partycji root, a rozwiązanie to niemal nie zajmuje miejsca na dysku, dopóki oba środowiska nie zaczną się od siebie różnić.

Czy moje wydanie FreeBSD jest nadal wspierane?

Każde wydanie jest wspierane przez określony czas, publikowany w formie tabeli gałęzi na stronie dotyczącej bezpieczeństwa. Według stanu na 25 października 2026 tabela ta wygląda następująco:

• releng/15.1, czyli 15.1-RELEASE, do 31 marca 2027
• releng/14.5, czyli 14.5-RELEASE, do 30 czerwca 2027
• releng/14.4, czyli 14.4-RELEASE, do 31 grudnia 2026
• stable/15 do 31 grudnia 2029
• stable/14 do 30 listopada 2028

Wydania punktowe otrzymują krótkie okresy wsparcia. Wersja 15.0-RELEASE nie znajduje się już w tabeli. W sierpniu 2026 roku widniała w niej z datą zakończenia 30 września 2026, nieco ponad trzy miesiące po tym, jak wersja 15.1 została wydana 16 czerwca 2026. Kolejnym wydaniem, którego wsparcie wygasa, jest 14.4-RELEASE, co nastąpi z końcem grudnia 2026. Gałęzie stabilne są wspierane przez lata; są to gałęzie źródłowe, których freebsd-update nie obsługuje.

Sprawdź własną wersję za pomocą freebsd-version -u i porównaj ją z tabelą. freebsd-update również wyświetla ostrzeżenia. W miarę zbliżania się daty końcowej, fetch wypisuje:

WARNING: FreeBSD 14.4-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

Po przekroczeniu tej daty ostrzeżenie zmienia się na WARNING: FreeBSD 14.4-RELEASE HAS PASSED ITS END-OF-LIFE DATE.. Niewspierane wydanie nadal działa. Przestaje jednak otrzymywać biuletyny bezpieczeństwa, co oznacza, że każda kolejna podatność w systemie bazowym pozostanie w nim na stałe.

Instrukcja aktualizacji FreeBSD 15.1 rozpoczyna proces aktualizacji wydania od freebsd-update fetch oraz freebsd-update install w celu zastosowania oczekujących poprawek. Następnie wykonuje się freebsd-update upgrade -r 15.1-RELEASE, potem freebsd-update install, restart do nowego jądra, a następnie ponownie freebsd-update install dla przestrzeni użytkownika. W tym momencie freebsd-update może zasugerować przebudowanie lub przeinstalowanie oprogramowania firm trzecich ze względu na zmiany w bibliotekach systemowych; strona aktualizacji zaleca postępowanie zgodnie z tymi instrukcjami w razie potrzeby. W przypadku przeskoku między głównymi wersjami, takimi jak 14.x do 15.1, ogólna procedura opisana w podręczniku realizuje to za pomocą pkg-static upgrade -f. Końcowe freebsd-update install usuwa nieaktualne pliki systemu bazowego. Podręcznik zaznacza, że w zależności od tego, czy numery wersji bibliotek uległy zmianie, mogą wystąpić tylko dwie fazy instalacji zamiast trzech. System pkgbase podlega osobnej procedurze pkg opisanej na tej samej stronie, a obie ścieżki kończą się aktualizacją programu rozruchowego. Zaplanuj okno serwisowe i przeczytaj przewodnik konfiguracji serwera FreeBSD 15 przed rozpoczęciem prac.

Restart czy wystarczy ponowne uruchomienie usługi?

FreeBSD odpowiada na to pytanie za pomocą jednego porównania:

freebsd-version -k
uname -r

freebsd-version -k to jądro na dysku. uname -r to jądro w pamięci. Różne ciągi znaków oznaczają, że zainstalowano nowe jądro, a aktualnie uruchomione jest stare, więc należy wykonać restart. Zgodne ciągi znaków oznaczają, że poprawka nie dotyczyła jądra, więc restart nie przyniesie żadnych korzyści.

W przypadku poprawek przestrzeni użytkownika należy zrestartować każdy proces korzystający ze zmodyfikowanego kodu. Poprawka biblioteki OpenSSL w /usr/lib nie wpłynie na sshd, który został uruchomiony trzy tygodnie temu i nadal ma w swojej przestrzeni adresowej zmapowaną starą bibliotekę. Plik na dysku jest nowy. Uruchomiony proces nie.

service sshd restart

Ta sama zasada dotyczy pakietów. pkg upgrade zastępuje plik binarny na dysku, podczas gdy uruchomiony proces nadal korzysta ze starej wersji, więc service nginx restart jest krokiem, który faktycznie wprowadza poprawkę w życie.

System bazowy nie posiada odpowiednika narzędzia needrestart znanego z Debiana, więc nic nie wyświetli monitu ani nie przechowa listy wymaganych działań. Należy samodzielnie śledzić, które usługi korzystają z poprawionej biblioteki, lub wykonać restart po każdej aktualizacji obejmującej biblioteki systemowe. Na serwerze, którego konfiguracja znajduje się w systemie kontroli wersji, restart jest rutynową operacją i jest znacznie tańszy niż błędne przekonanie o posiadaniu zainstalowanych poprawek.

Aktualizacja maszyny z uruchomionymi jailami

Jail współdzieli jądro systemu z hostem, dlatego ostrzeżenie dotyczące jądra dotyczy całego hosta, a każdy jail na maszynie dziedziczy ten problem. Po zaktualizowaniu hosta i jego restarcie, kwestia jądra zostaje rozwiązana dla wszystkich jaili. Przestrzeń użytkownika wewnątrz każdego jaila stanowi oddzielną instalację z własnym poziomem poprawek, a freebsd-version -j <jail> raportuje go z poziomu hosta. Pakiety wewnątrz jaila również są odrębne, a pkg -j <jail> audit -F przeprowadza ich audyt bez konieczności wchodzenia do jaila. Ten podział na współdzielone jądro i oddzielną przestrzeń użytkownika stanowi tę samą różnicę strukturalną, która definiuje porównanie jaili z kontenerami Docker.

Tłumaczenie na Ubuntu

Każdy nawyk z FreeBSD ma swój odpowiednik, dzięki czemu można przenieść rutynę w obu kierunkach.

• Łatki systemu bazowego: freebsd-update fetch, a następnie freebsd-update install. W systemie Ubuntu stosuje się apt update && apt upgrade, który obejmuje system bazowy oraz wszystkie pozostałe elementy jednocześnie.
• Oprogramowanie firm trzecich: pkg update && pkg upgrade w systemie FreeBSD. W systemie Ubuntu ponownie apt.
• Sprawdzanie znanych podatności: pkg audit -F w systemie FreeBSD. W systemie Ubuntu 24.04 najbliższym poleceniem jest pro security-status, które wyświetla aktualizacje bezpieczeństwa dla zainstalowanych pakietów, w tym zawartość Expanded Security Maintenance.
• Automatyczna instalacja: unattended-upgrades w systemie Ubuntu automatycznie stosuje aktualizacje bezpieczeństwa. FreeBSD nie posiada odpowiednika, dlatego freebsd-update cron pobiera i wysyła powiadomienia e-mail, podczas gdy instalację przeprowadza się ręcznie.
• Kanał z poradami: freebsd-security-notifications zawiera pozycje FreeBSD-SA oraz FreeBSD-EN. ubuntu-security-announce zawiera powiadomienia Ubuntu Security Notices.
• Baza danych podatności: VuXML dla portów i pakietów FreeBSD. Śledzenie CVE dla pakietów Ubuntu.
• Sprawdzanie konieczności restartu: freebsd-version -k w porównaniu z uname -r we FreeBSD. Obecność pliku /var/run/reboot-required w systemie Ubuntu.
• Okres wsparcia: tabela gałęzi na stronie bezpieczeństwa FreeBSD. Harmonogram wydań oraz pro security-status w systemie Ubuntu.

Podstawowa rutyna jest identyczna w obu systemach: subskrypcja kanału informacyjnego, uruchamianie audytu zgodnie z harmonogramem, a następnie decyzja o tym, co i kiedy zainstalować oraz kiedy wykonać restart. FreeBSD po prostu wymaga jawnego wykonania drugiej części procesu, ponieważ nie robi tego automatycznie. Szersze porównanie systemów Linux i FreeBSD jako platform serwerowych omawia pozostałe zmiany, które zachodzą podczas przenoszenia obciążenia między tymi systemami.

FAQ

Czy freebsd-update aktualizuje również pakiety?

Nie. freebsd-update obejmuje wyłącznie system podstawowy, czyli jądro oraz środowisko użytkownika dostarczone wraz z wydaniem. Oprogramowanie zainstalowane za pomocą /usr/local pochodzi z pakietów i jest aktualizowane przy użyciu pkg upgrade. Należy uruchomić pkg audit -F, aby sprawdzić, które zainstalowane pakiety posiadają znane luki bezpieczeństwa, ponieważ biuletyny systemu podstawowego nigdy ich nie wymieniają, a listy mailingowe dotyczące bezpieczeństwa nie publikują takich informacji.

Skąd wiadomo, czy aktualizacja FreeBSD wymaga restartu?

Należy porównać freebsd-version -k z uname -r. Pierwsze polecenie wyświetla wersję jądra zainstalowaną na dysku, w tym tę, która została właśnie zapisana, ale jeszcze nie uruchomiona. Drugie polecenie wyświetla wersję jądra, która jest aktualnie uruchomiona. Różne ciągi znaków oznaczają konieczność restartu. Zgodne ciągi oznaczają, że poprawka dotyczyła tylko środowiska użytkownika, więc należy zrestartować odpowiednie usługi, na przykład za pomocą service sshd restart, ponieważ uruchomiony proces utrzymuje starą bibliotekę w pamięci do momentu restartu.

Jaka jest różnica między Security Advisory a Errata Notice?

Security Advisory, takie jak FreeBSD-SA-26:55.elf, usuwa lukę bezpieczeństwa w systemie podstawowym. Errata Notice, takie jak FreeBSD-EN-26:18.tzdata, usuwa błąd w działaniu lub stabilności, który nie ma wpływu na bezpieczeństwo, na przykład nieaktualne dane stref czasowych. Oba typy dokumentów używają schematu: rok, dwukropek, numer porządkowy, komponent. Oba są podpisywane przez Security Officer i dostarczane przez freebsd-update, przy czym żaden z nich nie obejmuje oprogramowania zainstalowanego z ports lub packages.

Czy istnieje odpowiednik unattended-upgrades dla FreeBSD?

Nie w systemie podstawowym. freebsd-update cron pobiera oczekujące poprawki systemu podstawowego i wysyła powiadomienie na adres root, ale nigdy ich nie instaluje. Skrypt okresowy, który instaluje pkg, uruchamia pkg audit codziennie i wysyła wynik pocztą, ale również nie przeprowadza żadnych aktualizacji. Instalację bezobsługową należy skonfigurować samodzielnie za pomocą zadania cron. Ponieważ aktualizacja pakietu we FreeBSD pobiera najnowszą wersję, a nie tylko poprawkę bezpieczeństwa, większość administratorów czyta powiadomienia i przeprowadza aktualizację ręcznie.

Jak sprawdzić, czy wydanie FreeBSD jest nadal wspierane?

Należy uruchomić freebsd-version -u, aby sprawdzić wersję środowiska użytkownika, a następnie porównać ją z tabelą wspieranych gałęzi na stronie bezpieczeństwa FreeBSD. Wydania punktowe mają krótki okres wsparcia: według stanu na 25 października 2026, wsparcie dla 14.4-RELEASE kończy się 31 grudnia 2026, podczas gdy 15.1-RELEASE jest wspierane do 31 marca 2027, a 15.0-RELEASE nie jest już wspierane. freebsd-update fetch wyświetla ostrzeżenie w miarę zbliżania się daty końcowej, a po jej przekroczeniu drukuje informację, że wydanie OSIĄGNĘŁO DATĘ KOŃCA WSPARCIA (END-OF-LIFE DATE). Po tym terminie żadne kolejne biuletyny bezpieczeństwa nie dotyczą danej wersji.