search

haumacher / phoneblock

Der Spam-Filter für die Fritz!Box
https://phoneblock.net
GNU General Public License v3.0
161 stars 15 forks source link

Dependency Aktualisierungen #7

Open XSpielinbox opened 2 years ago

XSpielinbox commented 2 years ago

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.
haumacher commented 2 years ago

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...

XSpielinbox commented 2 years ago

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?

haumacher commented 2 years ago

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

haumacher commented 2 years ago

Google-APIs werden jetzt in version 2.0 verwendet.

haumacher commented 2 years ago

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

image

haumacher commented 2 years ago

OpenCSV ist jetzt auf der neusten Version.

XSpielinbox commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

haumacher commented 2 years ago

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.

XSpielinbox commented 2 years ago

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 commented 2 years ago

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.

haumacher commented 2 years ago

...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 commented 2 years ago

... 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 commented 2 years ago

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

XSpielinbox commented 2 years ago

... 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

haumacher commented 2 years ago

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 commented 2 years ago

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

Siehe 2284d88

haumacher commented 2 years ago

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 commented 2 years ago

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

:-)

XSpielinbox commented 2 years ago

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 commented 2 years ago

Siehe 2284d88

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

XSpielinbox commented 2 years ago

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

https://xkcd.com/927/

XSpielinbox commented 2 years ago

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?

haumacher commented 2 years ago

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.