phoneblock icon indicating copy to clipboard operation
phoneblock copied to clipboard

Dependency Aktualisierungen

Open XSpielinbox opened this issue 2 years ago • 28 comments

Hallo,

  1. Warum wird noch Java 11 verwendet?
  2. Warum sind die Versionen mancher verwendeter Bibliotheken so alt?
  • [ ] Warum wird javax.servlet-api 3.1.0 von 2013 genutzt anstatt jakarta.servlet-api 6.0 von diesem Jahr? Java EE ist ja jetzt auch in Jakarta EE übergegangen.
  • [x] Bei google-api-client 1.32.1 gibt es nach Maven Central auch Sicherheitslücken, die in neueren Versionen - derzeit 2.0.0 - behoben sind.
  • [ ] httpcore wurde auch zu httpcore5 migriert. Die neuste Version von httpcore ist 4.4.16, die neuste Version von httpcore5 ist 5.2. Nach Maven Central hat 5.2 auch keine bekannten Sicherheitslücken mehr.
  • [x] opencsv 4.1 hat ja auch mehrere bekannte Schwachstellen. opencsv 5.7.0 hat leider auch eine, aber auch hier eine andere.
  • [x] backend von org.shredzone.shariff hat in der verwendeten Version 1.15 auch eine Schwachstelle, die Version 1.23 nicht mehr hat.
  • [ ] javax.mail ist ja auch in jakarta.mail aufgegangen, wo die 2.0.1 nicht mehr die Sicherheitslücke der verwendeten 1.6.2 hat.
  • [x] Das verwendete junit ist ja auch von 2007 noch und da einige der neueren Versionen diverse Probleme haben, würde ich davon ausgehen, dass das bei der auch der Fall ist. Die Nachfolge ist ja schon seit 2016 junit-jupiter-api, derzeit Version 5.9.1.

XSpielinbox avatar Oct 18 '22 21:10 XSpielinbox

Java 11, weil Debian buster kein Java 17 hat und das meine Zielplatform war, könnte man mittlerweile aber updaten, ja. javax.servlet-api ist so ein Punkt - da haben sich alle Packages geändert und es gibt keine Rückwärtskompatibilität mehr, da muss wirklich alles dazupassen - inklusive der Container - werde ich mal ausprobieren. google-api-client - guter Punkt - aber nachdem ich diese idiotisch komplizierte Google-Upate-API nach einer Google-Anleitung implementiert und konfiguriert hatte, nur um danach festzustellen, dass die Anleitung out-of-date war und sich auf eine deprecated API bezog war ich so genervt, dass ich das einfach so gelassen habe...

haumacher avatar Oct 19 '22 05:10 haumacher

Vielen Dank für die schnelle Antwort. Ich habe mal die Liste in meiner ursprünglichen Nachricht um die weiteren Abhängigkeiten, die jetzt anders heißen, extrem veraltet sind oder nach Maven Central Sicherheitslücken aufweisen ergänzt. Abhängigkeiten aus diesem Jahr, wo zwar auch neuere Versionen existieren, aber keine bekannten Sicherheitsprobleme existieren, sind daher nicht genannt. Kann die Checkliste in meiner Nachricht eigentlich nur ich oder auch jemand anderes abhaken?

XSpielinbox avatar Oct 19 '22 08:10 XSpielinbox

Cool - ja, ich kann auch auf so ein Häckchen clicken...

haumacher avatar Oct 19 '22 10:10 haumacher

Google-APIs werden jetzt in version 2.0 verwendet.

haumacher avatar Oct 19 '22 20:10 haumacher

Die Bibliothek httpcore lässt sich nicht updaten, weil sie eine Abhängigkeit auch der neusten Version der Google-APIs ist:

image

haumacher avatar Oct 19 '22 20:10 haumacher

OpenCSV ist jetzt auf der neusten Version.

haumacher avatar Oct 19 '22 20:10 haumacher

Die Bibliothek httpcore lässt sich nicht updaten, weil sie eine Abhängigkeit auch der neusten Version der Google-APIs ist:

Ah, ok. Dann muss man das halt beobachten. So einwandfrei ist ja httpcore5 leider auch noch nicht...

XSpielinbox avatar Oct 19 '22 22:10 XSpielinbox

Google-APIs werden jetzt in version 2.0 verwendet.

Cool, danke! Warum ist es dafür erforderlich google-auth-library-oauth2-http als neue Abhängigkeit und dann auch noch nur in Version 1.3.0 einzuführen?

XSpielinbox avatar Oct 19 '22 22:10 XSpielinbox

javax.servlet-api ist so ein Punkt - da haben sich alle Packages geändert und es gibt keine Rückwärtskompatibilität mehr, da muss wirklich alles dazupassen - inklusive der Container - werde ich mal ausprobieren.

Ja, wobei ich davon ausgehe, dass es mit dem namespace change schon weitestgehend erledigt ist und dabei können einem ja auch tools helfen, z. B. IntelliJ oder Tomcat Migration Tool for Jakartaee

XSpielinbox avatar Oct 19 '22 22:10 XSpielinbox

Cool, danke! Warum ist es dafür erforderlich google-auth-library-oauth2-http als neue Abhängigkeit und dann auch noch nur in Version 1.3.0 einzuführen?

Die Abhängigkeit ist notwendig, um die Deprecation in com.google.api.client.googleapis.auth.oauth2.GoogleCredential zu entfernen. Version 1.3.0 ist natürlich vollkommener Blödsinn - Update in 099034f vorgenommen.

haumacher avatar Oct 21 '22 19:10 haumacher

Also zumindest das deployen von dem WAR geht noch einwandfrei auch mit source- und target-java-version 17. Außerdem habe ich den Eindruck, dass opencsv und damit commons-text nur test dependencies sind, zum compilen werden sie auf jeden Fall nicht benötigt. Genauso ist zwar httpcore derzeit eine transitive Abhängigkeit, aber das Projekt selbst braucht es weder zur compile noch test Zeit. Sofern ich jetzt nichts zur runtime übersehen habe, kann man damit doch die Abhängigkeiten als test-Abhängigkeiten deklarieren bzw. gänzlich entfernen.

XSpielinbox avatar Oct 22 '22 12:10 XSpielinbox

javax.servlet-api ist so ein Punkt - da haben sich alle Packages geändert und es gibt keine Rückwärtskompatibilität mehr, da muss wirklich alles dazupassen - inklusive der Container - werde ich mal ausprobieren.

Zumindest ein Update auf junit 4.13.2 und javax.servlet-api 4.0.1 scheint ohne Code Änderungen zu gehen.

XSpielinbox avatar Oct 22 '22 21:10 XSpielinbox

...den Eindruck, dass opencsv ... nur test dependencies sind ...

Vgl. de.haumacher.phoneblock.analysis.NumberAnalyzer.buildTree() - OpenCSV wird verwendet, um die Vorwahl-Datenbank der Bundesnetzargentur einzulesen: /phoneblock/src/main/java/de/haumacher/phoneblock/analysis/NVONB.INTERNET.20220727.ONB.csv

haumacher avatar Oct 23 '22 06:10 haumacher

... Genauso ist zwar httpcore derzeit eine transitive Abhängigkeit, aber das Projekt selbst braucht es weder zur compile noch test Zeit....

Solche Abhängigkeiten sind extrem schwer zu analysieren. Man kann das eigentlich erst merken, wenn man eine module-info.java Datei hinzufügt (a9db46f), damit alles, was man nicht explizit zur Abhängigkeit gemacht hat nicht mehr sichtbar ist. Wenn man das tut, dann sieht man, dass es tatsächlich eine winzig kleine direkte Abhängigkeit zu httpcore gibt:

de.haumacher.phoneblock.carddav.resource.Resource.propfind(HttpServletRequest, Resource, Element, List<Element>) benutzt org.apache.http.impl.EnglishReasonPhraseCatalog um eine korrekte HTTP-Status-Code-Nachricht zu produzieren. Ob das jetzt gut oder schlecht ist, mag mal dahingestellt sein, aber wenn man ohnehin eine transitive Ahbängigkeit zu dem Modul hat, warum dann nicht auch ein kleines Utility davon nutzen...

haumacher avatar Oct 23 '22 07:10 haumacher

Habe die Tests nach JUnit 5 migriert - bin zwar kein Fan von dem Annotations-Zeugs, aber man muss ja was neues lernen... :-)

haumacher avatar Oct 23 '22 20:10 haumacher

... OpenCSV wird verwendet, um die Vorwahl-Datenbank der Bundesnetzargentur einzulesen...

ok, da muss ich mich also geirrt haben. Interessanterweise kompiliert das Projekt auch ohne die Deklaration in der pom.xml, ich konnte aber es nirgendswo als transitive Abhängigkeit finden.

XSpielinbox avatar Oct 23 '22 20:10 XSpielinbox

Solche Abhängigkeiten sind extrem schwer zu analysieren. Man kann das eigentlich erst merken, wenn man eine module-info.java Datei hinzufügt (a9db46f), damit alles, was man nicht explizit zur Abhängigkeit gemacht hat nicht mehr sichtbar ist. Wenn man das tut, dann sieht man, dass es tatsächlich eine winzig kleine direkte Abhängigkeit zu httpcore gibt:

Ah, super! Wie wurde die modul-info.java erstellt? Manuell oder durch ein Tool generiert? Und selbst wenn es keine transitive Abhängigkeit wäre, solange man die Funktionalität gut gebrauchen kann und sie keinen Schaden anrichtet, warum nicht nutzen? Aber wenn es eine selbst verwendete Dependency ist und dann noch auch so "trivial", dann spricht doch nichts dagegen, das Update auf httpcore5 durchzuführen? Dadurch, dass das Artifakt umbenannt wurde, kommt man doch in keinerlei Schwierigkeiten mit der Transitiven Abhängigkeit von Google. Zumindest kompilieren und deployen geht, auch mit dem Update. Angesichts das ich mich da aber schon einmal geirrt habe, gut möglich, dass ich es hier nochmal tue.

XSpielinbox avatar Oct 23 '22 21:10 XSpielinbox

Habe die Tests nach JUnit 5 migriert - bin zwar kein Fan von dem Annotations-Zeugs, aber man muss ja was neues lernen... :-)

Gut, das ist wahrscheinlich eine Frage der persönlichen Präferenz...

Aber wo das Dependency-Check Plugin eine Aktualisierung erfahren hat: Ich glaube bei dem maven-compiler-plugin wäre auch mal die Aktualisierung auf 3.10.1 sehr ratsam. Die verwendete Version liegt da ja auch schon 4 Jahre zurück und enthält bekannte Schwachstellen.

XSpielinbox avatar Oct 23 '22 22:10 XSpielinbox

Und noch eine Sache: Warum ist commons-logging als Dependency von opencsv als auch google-api-client ausgenommen? Gemäß Maven sollte ja (verständlicherweise) so eine Exclusion nur das aller letzte Mittel sein, weil es potentiell großen Schaden anrichten kann. Ich kann zudem nicht finden, dass es überhaupt eine Abhängigkeit von opencsv ist und die von google-api-client verwendete Version hat keine Sicherheitslücken, die ich finden konnte und das Programm scheint auch zu gehen, wenn man sie (wie ja eigentlich intendiert) mit als Dependency nimt. Wenn man da sorgen hat, ein zukünftiges Problem zu übersehen, kann man ja den OWASP Dependency-check als Teil der Verify Lifecycle stage oder so einrichten, dass er immer mitgemacht wird.

XSpielinbox avatar Oct 24 '22 10:10 XSpielinbox

Wie wurde die modul-info.java erstellt?

Eclipse hat ein Tool im Projekt-Menü "Configure" mit Namen "Create module-info.java". Das erstellt zumindest einen Vorschlag, den man noch anpassen kann/muss. Leider erstellt es nicht die entsprechende Variante in src/test/java, damit es auch mit dem Testen noch funktioniert. Hat mich mehrere Stunden gekostet herauszufinden in welcher Kombination alle zufrieden sind - Eclipse und Maven...

haumacher avatar Oct 25 '22 19:10 haumacher

... maven-compiler-plugin wäre auch mal die Aktualisierung auf 3.10.1 sehr ratsam...

Siehe 2284d88

haumacher avatar Oct 25 '22 20:10 haumacher

Und noch eine Sache: Warum ist commons-logging als Dependency von opencsv als auch google-api-client ausgenommen?

Logging-Frameworks sind die Hölle - insbesondere weil es mehr als eines gibt. opencsv nutzt als Logging-Framework commons-logging und zieht damit als dependency die Klassen von commons-logging an. PhoneBlock nutzt aber slf4j als Logging-API und tinylog-impl als Logging-Implementierung. Damit jetzt auch tatsächlich alle getätigten Log-Ausgaben, auch die von abhängignen Bibliotheken, in derselben Ausgabe landen, muss man das Logging für alle Bibliotheken, die eine andere Logging-API als die von PhoneBlock nutzen, so umbiegen, dass diese ebenfalls de-facto über slf4j loggen. Dafür gibt es von slf4j Adapter-Implementierungen für alle "gängigen" Logging-Abarten, so auch für commons-logging (nämlich jcl-over-slf4j). Diese Adapter-Implementierungen stellen dieselben Klassen wie die originale Implementierung zur Verfügung, loggen de-facto aber über die Mechanik von slf4j. Darum muss man die ursprünglichen Logging-Dependencies ausschließen, sonst hat man doppelte Klassen im Classpath und das Ergebnis ist zufällig:

grafik

haumacher avatar Oct 25 '22 20:10 haumacher

Neue Version ist online: https://phoneblock.net/phoneblock/status.jsp

:-)

haumacher avatar Oct 25 '22 20:10 haumacher

Eclipse hat ein Tool im Projekt-Menü "Configure" mit Namen "Create module-info.java". Das erstellt zumindest einen Vorschlag, den man noch anpassen kann/muss. Leider erstellt es nicht die entsprechende Variante in src/test/java, damit es auch mit dem Testen noch funktioniert. Hat mich mehrere Stunden gekostet herauszufinden in welcher Kombination alle zufrieden sind - Eclipse und Maven...

Ah, ok. Danke.

XSpielinbox avatar Oct 26 '22 18:10 XSpielinbox

Siehe 2284d88

man lernt echt nie aus. Das maven versions plugin ist ja echt cool!

XSpielinbox avatar Oct 26 '22 18:10 XSpielinbox

Logging-Frameworks sind die Hölle - insbesondere weil es mehr als eines gibt.

https://xkcd.com/927/

XSpielinbox avatar Oct 26 '22 18:10 XSpielinbox

Neue Version ist online: https://phoneblock.net/phoneblock/status.jsp

:-)

Sehr gut! Gibt es eine gute Möglichkeit, um auf der Webseite einzusehen, auf welchem Commit / welcher Version die laufende Version der Webseite basiert?

XSpielinbox avatar Oct 26 '22 18:10 XSpielinbox

auf der Webseite einzusehen, auf welchem Commit / welcher Version die laufende Version der Webseite basiert

grafik

Ein Tooltip über "PhoneBlock" im Footer zeigt den Build-Zeitpunkt, nicht genau die Git-Version.

haumacher avatar Nov 01 '22 22:11 haumacher