Zalecana i bezpieczna Java?

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:

Przechodząc do pytań:

  1. Czy ktoś ma orientację, czy szeroko opisywane podatności Javy dotyczą wszystkich systemów, w tym też pakietów OpenJDK w Linuksie?
  2. 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 :slight_smile: 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.
    2019-07-22_192949

Ten wpis został oflagowany przez społeczność i został tymczasowo ukryty.

omg usun te open javy przez -Rdd - niema zaco mialem ten “problem” i to dziala wiec niekasowac

haha literka misie pomylila