Korzystam czasami z pakietów bazujących na Java i, w kontekście różnych niejednoznacznych informacji, zastanawiam się, którą wersję Java należałoby używać i na ile jest to bezpieczne w Linuksie.
Poniżej, w skrócie dla zainteresowanych, przedstawiam zestawienie podstawowych faktów:
Oracle namieszał totalnie z licencjami, kończąc z dotychczas darmowym użytkowaniem i wyprowadzając system opłat subskrypcyjnych, choć ponoć nie dotyczy to użytku osobistego;
najnowsza darmowa wersja Java, zalecana przez Oracle to Java 8 Update 221 z 16.07.2019r.;
Czy ktoś ma orientację, czy szeroko opisywane podatności Javy dotyczą wszystkich systemów, w tym też pakietów OpenJDK w Linuksie?
Obecnie mam zainstalowaną Javę OpenJDK wersję “1.8.0_222” (, co odpowiada z grubsza numeracji darmowej wersji zalecanej przez Oracle). Nie pamiętam dlaczego zainstalowałem wersję 8, jednak wydaje mi się, że bezpieczniejsza powinna być najnowsza wersja 12 (która ukryta jest w pakietach bez numeru, np.: jre-openjdk, jre-openjdk-headless i jdk-openjdk (być może nie widząc tego numeru, zainstalowałem swego czasu omyłkowo wtedy najnowszą jre8-openjdk).
Czy zatem mam prawo i powinienem odinstalować wersję 8 i zainstalować wersję 12?
używaj najnowszych wersji dostępnych w repozytoriach systemowych. Zmniejsza się, dzięki temu, prawdopodobieństwo wystąpienia podatności, czy innych błędów;
jeżeli, w danej chwili, żaden pakiet nie wymaga Javy, to odinstaluj ją (nie instaluj jako samodzielnego pakietu, tylko jako zależność);
to z jakiej wersji korzystasz, może być wymuszone przez inne używane pakiety, które mogą mieć swoje wymagania, co do wersji pakietów zależnych;
zazwyczaj, numery wersji w nazwach pakietów występują wtedy, gdy są to starsze wersje danego programu/biblioteki. Bez numeru jest pakiet w wersji najnowszej lub ‘domyślnej’ dla repo;
Java jest jedna na wszystkie wspierane systemy, a więc i podatności, są wspólne. Z drugiej strony, na poszczególne systemy potrzebne, są natywne maszyny wirtualne Javy, a i same systemy różnią się między sobą na tyle, że poszczególne podatności mogą być na nich groźne lub nie (to tylko opinia, która opiera się na wiedzy ogólnej, a nie znajomości Javy);
wyższe numery wersji głównych nie świadczą o większym bezpieczeństwie, tylko o innym, większym zakresie funkcjonalności. Jeżeli wyższe, jak i niższe numery, są nadal rozwijane i wydawane, są do nich poprawki bezpieczeństwa, to poziom bezpieczeństwa może być porównywalny.
Przejrzałem zainstalowane pakiety, które korzystają z Java i widzę, że chyba żadne nie wymagają bezpośrednio składników Java werja 8.
Natomiast jest mechanizm pośredni: pakiet nadrzędny posiada zależność java-runtime, która może składać się ze składników Java w różnych wersjach (przykład: pakiet jdownloader2).
Chcę zatem odinstalować roboczo wszystkie składniki Java 8, bez odinstalowywania ich pakietów nadrzędnych (szczególnie tych z AUR, aby ich potem nie budować od nowa).
Następnie chciałbym reinstalować te pakiety nadrzędne, licząc na to, że zainstalują, pośrednio poprzez java-runtime najnowsze, domyślne składnik Java, tj. w wersji 12.
Próbowałem przez pamac, ale ten chce odinstalowywać zbyt wiele pakietów nadrzędnych i obawiam się, że mogę stracić kontrolę nad systemem.
Z pacman wygląda to łatwiej, jednak jest błąd:
sudo pacman -Rs jre8-openjdk
sprawdzanie zależności…
błąd: nie udało się przygotować transakcji (nie udało się rozwiązać zależności)
:: jdownloader2: usuwanie jre8-openjdk łamie zależność 'java-runtime'
:: webcamstudio-git: usuwanie jre8-openjdk łamie zależność 'java-runtime'
Zatem jak odinstalować pakiety z Javą 8, bez odinstalowania pakietów nadrzędnych (jak wyżej) lub inaczej rozwiązać ten problem?
No właśnie, skąd masz tą 8-kę? Mniejsza o to, spróbuj zainstalować (bez odinstalowywania czegokolwiek) jre-openjdk (extra). Być może, jeżeli nie masz rozbudowanych zależności, to pamac zaproponuje odinstalowanie jre8-openjdk i zainstalowanie jre-openjdk. Sprawdź.
@majo
Ja przestałem używać Jdownloader2 z AUR z tego względu że znalazłem zamiennik Uget który to potrzebuje jednej zależności, czyli aria2. A Jdownloader2 to jest kobyła.
Dzięki. Udało się doinstalować bezproblemowo jre-openjdk.
Po tej operacji zależność java-runtime wskazywała poprawnie na wersję Java 12.
Dalej odinstalowałem jre8-openjdk.
Jednak coś nie działało. Nie można było uruchomić pakietów nadrzędnych, a proste uruchomienie java -jar pakietJava.jar generowało błąd bash: java: nie znaleziono polecenia.
Idąc tą drogą, sprawdziłem, że w katalogu /sbin plik java z dowiązaniem symbolicznym do /usr/lib/jvm/default-runtime/bin/java i okazało się, że był oznaczony jako błędny (i stąd nie można było znaleźć polecenia java).
Jak sprawdziłem, w katalogu /usr/lib/jvm nie było podkatalogu default-runtime.
Doinstalowałem jeszcze jeden pakiet jdk-openjdk (choć chyba go nie potrzebuję), licząc, że jego instalacja uzupełni i przywróci poprawne linki symboliczne i katalogi. I tak się stało.
Obecnie wszystko działa poprawnie, jak wcześniej.
(Wprawdzie w w katalogu /sbin plik javah z dowiązaniem symbolicznym do /usr/lib/jvm/default/bin/javah jest oznaczony jako błędny i nie widzę we wskazanym katalogu pliku javah, ale chyba nie będę potrzebować tego pliku javah.)
@robson75 jdownloader2 to kobyła, jednak posiadająca znacznie więcej możliwości od uget (który także posiadam).
Oj, coś żeście @majo nagrzebali w systemie, skoro takie rzeczy wypływają. Musisz liczyć się z tym, że nadal będą, tu i ówdzie znienacka, bo to nie wygląda na prawidłową reakcję systemu. Raz zepsuta spójność bazy manager’a pakietów i synchronizacja pomiędzy nią, a systemem plików może ciągnąć się długo, a nawet eskalować.
Ale ten problem rozwiązany - nie ma wersji, której nie lubimy, a jest ta, której pragnęliśmy.
Chyba jednak nie ja nagrzebałem Staram się być z tym ostrożny.
Przeprowadziłem gruntowne śledztwo, a oto szczegóły:
W katalogu /bin mam osiem plików z błędnymi linkami symbolicznymi (pliki z czerwoną ikonką na rys. poniżej).
Pliki te zostały utworzone przez przez pakiet java-runtime-common oraz java-environment-common i wskazują na pliki docelowe, które powinny się znajdować w katalogu /usr/lib/jvm/default-runtime/bin/. Te dwa pakiety były zbudowane 22. września 2017r. i taka jest data plików na rys. poniżej.
Powyższe dwa pakiety są zależnościami odpowiednio ZARÓWNO pakietów jre-openjdk-headless i jre8-openjdk-headless oraz ZARÓWNO pakietów jdk-openjdk i jdk8-openjdk.
W wersji Java 8 istniały wszystkie pliki docelowe w /usr/lib/jvm/default-runtim/bin/ jednak nie ma tych plików w wersji Java 12, a pakiety java-runtime-common oraz java-environment-common (niezmienione od 2 lat) “pamiętają” strukturę plików z wersji Java 8, a może i wcześniejszej, stąd błędne odwołania, widoczne poniżej.
Staram się być z tym ostrożny.