MD5 Checksum stimmt nicht überein
Moin zusammen,
wir haben auf unserer Homepage ein Software-ISO mit ca. 1,9 GB zum Download für unsere Kunden (meist Handwerker mit nur PC-Grundkenntnissen).
Nun bekommen wir immer häufiger Rückmeldungen, dass die von uns angegebene MD5 Checksum nicht übereinstimmt, wenn diese die mit WinMD5free gegenprüfen (Anleitung dazu ist online).
Wenn ich das dann bei mir runterlade und prüfe, passt alles. Aufgefallen ist mir, dass es sich um PCs mit Windows11 handelt. Ich hab hier ein älteres W11 auf einer VM und es damit getestet, auch i.O.
Jemand irgend eine Idee was das sein könnte? Oder auch ähnliche Erfahrungen gemacht?
Ich möchte eben ungern dass die Leute das installieren wenn die MD5 nicht übereinstimmt...
Danke für Euren Input
:: m.ster
wir haben auf unserer Homepage ein Software-ISO mit ca. 1,9 GB zum Download für unsere Kunden (meist Handwerker mit nur PC-Grundkenntnissen).
Nun bekommen wir immer häufiger Rückmeldungen, dass die von uns angegebene MD5 Checksum nicht übereinstimmt, wenn diese die mit WinMD5free gegenprüfen (Anleitung dazu ist online).
Wenn ich das dann bei mir runterlade und prüfe, passt alles. Aufgefallen ist mir, dass es sich um PCs mit Windows11 handelt. Ich hab hier ein älteres W11 auf einer VM und es damit getestet, auch i.O.
Jemand irgend eine Idee was das sein könnte? Oder auch ähnliche Erfahrungen gemacht?
Ich möchte eben ungern dass die Leute das installieren wenn die MD5 nicht übereinstimmt...
Danke für Euren Input
:: m.ster
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671677
Url: https://administrator.de/forum/md5-checksum-stimmt-nicht-ueberein-671677.html
Ausgedruckt am: 01.04.2025 um 02:04 Uhr
36 Kommentare
Neuester Kommentar
Zitat von @m.ster:
@LordGurke danke, es betrifft leider mit dem 11er virus microsoft-belastete Umgebungen ;)
@LordGurke danke, es betrifft leider mit dem 11er virus microsoft-belastete Umgebungen ;)
es geht ja auch um eine Kontrollgruppe, um zu zeigen, wo es läuft (und nicht nur, wo es nicht läuft) 😉
Tippe aber weiterhin unabhängig davon, dass das ein spezifisches Problem eines Endusers ist.
Das Problem ist leicht reproduzierbar: Du musst nur mit ausreichend geringer Geschwindigkeit herunterladen (ich habe das jetzt mal mit 20 Mbps simuliert), dann bricht das ab und dann kann natürlich auch die Checksumme nicht stimmen.
Der Hintergrund dafür ist, dass die Datei über PHP ausgeliefert wird:
Zudem gibt es keinen "Content-Length:"-Header, in dem stünde, wie groß die Datei ist. Der Client weiß daher auch nicht, wann ein Download abbricht oder regulär zu Ende ist.
Lade ich mit den simulierten 20 Mbps herunter, bricht der Download nach exakt 9 Minuten ab, was vermutlich die maximal erlaubte Laufzeit für PHP-Scripte auf dem Server ist.
In der Zeit kann die Datei nicht vollständig übertragen werden, wenn die Geschwindigkeit eben zu niedrig ist. Der Client weiß allerdings auch nicht, dass der Download unvollständig ist, weil ihm nicht mitgeteilt wurde, wie groß die Datei sein müsste und zeigt deshalb auch keinen Fehler an.
In den 08:59 Minuten, die der Download dauerte, habe ich nur knapp über 1 GiB herunterladen können. Es fehlen damit also 950 MiB gegenüber der originalen Datei.
Wer jetzt sagt: "So langsame Internetzugänge findet man doch kaum noch" – ältere Tarife haben teilweise nur 20 bis 25 Mbps und den Firmen reicht das vermutlich auch locker aus. Die laden damit ein paar E-Mails und sind zufrieden.
Wie stellt man das jetzt ab?
Ganz einfach: Nicht durch ein PHP-Script ausliefern lassen sondern mit einem direkten Link auf die Datei auf dem Server. Also klassisch per (S)FTP ein Verzeichnis anlegen, Datei hochladen, Link zu https://..../verzeichnis/datei.iso auf der Webseite setzen.
PHP-Scripte haben eine maximale Laufzeit, danach werden sie abgebrochen. Man kann an diesen Werten herumschrauben, aber es hat ja auch andererseits gute Gründe, warum Scripte eine Zeitbegrenzung für die Ausführung haben. Und der Download durch PHP erzeugt auch unnötig Last auf dem Server.
So wie ich das sehe, ergibt sich durch den Download durch dieses Script auch überhaupt kein Vorteil gegenüber einem direkten Downloadlink zu einer Datei auf dem Server. Ganz im Gegenteil sogar, denn der Server würde a) keine Beschränkung der Download-Dauer haben und b) sogar anbieten, abgebrochene Downloads wieder aufzunehmen.
Der Hintergrund dafür ist, dass die Datei über PHP ausgeliefert wird:
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
$ curl --head 'https://<redacted>/download?task=download.send&id=1&catid=2&m=0'
HTTP/2 200
server: nginx
date: Fri, 07 Mar 2025 16:10:21 GMT
content-type: application/octet-stream
x-powered-by: PHP/8.2.27 <-- Auslieferung durch PHP
cache-control: private, max-age=0, must-revalidate, no-store
content-disposition: attachment; filename="<redacted>.iso"
x-content-type-options: nosniff
last-modified: Fri, 22 Sep 2023 10:48:18 GMT
x-powered-by: PleskLin
Zudem gibt es keinen "Content-Length:"-Header, in dem stünde, wie groß die Datei ist. Der Client weiß daher auch nicht, wann ein Download abbricht oder regulär zu Ende ist.
Lade ich mit den simulierten 20 Mbps herunter, bricht der Download nach exakt 9 Minuten ab, was vermutlich die maximal erlaubte Laufzeit für PHP-Scripte auf dem Server ist.
In der Zeit kann die Datei nicht vollständig übertragen werden, wenn die Geschwindigkeit eben zu niedrig ist. Der Client weiß allerdings auch nicht, dass der Download unvollständig ist, weil ihm nicht mitgeteilt wurde, wie groß die Datei sein müsste und zeigt deshalb auch keinen Fehler an.
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
$ wget 'https://<redacted>/download?task=download.send&id=1&catid=2&m=0' -O '<redacted>.iso-veryslowdownload' --limit-rate=2m
--2025-03-07 13:47:50-- https://<redacted>/download?task=download.send&id=1&catid=2&m=0
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Connecting to <redacted> (<redacted>)|109.xxxxxxxx|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/octet-stream]
Saving to: ‘<redacted>.iso-veryslowdownload’
<redacted>.iso-veryslowdown [ <=> ] 1.00G 2.00MB/s in 8m 59s
2025-03-07 13:56:50 (1.91 MB/s) - ‘<redacted>.iso-veryslowdownload’ saved [1079498752]
In den 08:59 Minuten, die der Download dauerte, habe ich nur knapp über 1 GiB herunterladen können. Es fehlen damit also 950 MiB gegenüber der originalen Datei.
Wer jetzt sagt: "So langsame Internetzugänge findet man doch kaum noch" – ältere Tarife haben teilweise nur 20 bis 25 Mbps und den Firmen reicht das vermutlich auch locker aus. Die laden damit ein paar E-Mails und sind zufrieden.
Wie stellt man das jetzt ab?
Ganz einfach: Nicht durch ein PHP-Script ausliefern lassen sondern mit einem direkten Link auf die Datei auf dem Server. Also klassisch per (S)FTP ein Verzeichnis anlegen, Datei hochladen, Link zu https://..../verzeichnis/datei.iso auf der Webseite setzen.
PHP-Scripte haben eine maximale Laufzeit, danach werden sie abgebrochen. Man kann an diesen Werten herumschrauben, aber es hat ja auch andererseits gute Gründe, warum Scripte eine Zeitbegrenzung für die Ausführung haben. Und der Download durch PHP erzeugt auch unnötig Last auf dem Server.
So wie ich das sehe, ergibt sich durch den Download durch dieses Script auch überhaupt kein Vorteil gegenüber einem direkten Downloadlink zu einer Datei auf dem Server. Ganz im Gegenteil sogar, denn der Server würde a) keine Beschränkung der Download-Dauer haben und b) sogar anbieten, abgebrochene Downloads wieder aufzunehmen.
Danke an LordGurke für die fundierte Stellungnahme und Lösung. Ist ja an sich mal wieder ein bisschen die Glaskugel gewesen, denn ich wäre nicht auf die Idee gekommen, dass eine x Gigabyte große Downloaddatei über Skripte läuft.
@to: Umstellen, wie von LordGurke bestens beschrieben, alles andere macht keinen Sinn.
@to: Umstellen, wie von LordGurke bestens beschrieben, alles andere macht keinen Sinn.
Hallo,
@LordGurke: Sehr gute Darstellung und Lösung.
@m.ster:
Für eine einfache Hash-Prüfung ware "HashCheck Shell Extension" eine Alternative:
Original: code.kliu.org
Weiterentwicklung: github
Neben einer kleinen Installation (mit Neustart), ansonsten wesentlich flexibler und schneller.
Wenn Hash-Datei zum Download verfügbar, genügt ein Doppelklick darauf.
Gruß KoDiAk
@LordGurke: Sehr gute Darstellung und Lösung.
@m.ster:
Für eine einfache Hash-Prüfung ware "HashCheck Shell Extension" eine Alternative:
Original: code.kliu.org
Weiterentwicklung: github
Neben einer kleinen Installation (mit Neustart), ansonsten wesentlich flexibler und schneller.
Wenn Hash-Datei zum Download verfügbar, genügt ein Doppelklick darauf.
Gruß KoDiAk
Ich bin jetzt auch kein Joomla-Profi, nehme aber mal an, dass die per .htaccess-Datei normalerweise verhindern, dass jemand direkt Dateien aus dem Verzeichnis abrufen kann, in dem die Downloads gespeichert werden.
Wenn man den Download per PHP-Script abschaltet, muss natürlich gleichzeitig dieser andere Zugriffsschutz auch abgeschaltet werden (wenn er überhaupt aktiviert ist).
Das dürfte vermutlich auch einfach so ein Schalter sein, in irgendeinem Tab der "Sicherheitsrelevante Einstellungen" heißt.
Wenn man den Download per PHP-Script abschaltet, muss natürlich gleichzeitig dieser andere Zugriffsschutz auch abgeschaltet werden (wenn er überhaupt aktiviert ist).
Das dürfte vermutlich auch einfach so ein Schalter sein, in irgendeinem Tab der "Sicherheitsrelevante Einstellungen" heißt.