Prüfmethoden für Updates

**TheMiller**

Hallo,

nach einer längeren - berufsbedingten - Abstinenz von Delphi, melde ich mich nun wieder zurück!

Ich überlege gerade, ob es nicht an der Zeit wäre, meinen bis jetzt funktionierenden Updater etwas zu verbessern und wollte mich daher mal nach anderen Funktionsweisen erkundigen. Derzeit funktioniert mein Updater wie folgt: Es wird lokal geprüft, welche Programmdateien existieren, welche Versionsinformation jeweils einkompiliert wurde und dazu noch der md5-Hash einer Datei erzeugt. Danach wird auf dem Update-Server eine ini-Liste heruntergeladen und die lokale mit remote-Liste abgeglichen. Alle Dateien, die remote einen anderen md5-Hash, eine andere Versionsnummer haben oder lokal nicht existieren, sind sind upzudaten. Ich dachte damals, dass man so manipulationen an Dateien ausschließen kann.

Doch irgendwie scheine ich der einzige zu sein, der Updates am md5-Hash ermittelt. Gibt es einen Grund dafür, welche andere Systeme/Merkmale gibt es, wie handhabt ihr die gesamte Update-Prozedur (von Erstellen/Publizieren, bis zur Prüfung und Installation).

Mal wieder "Danke im Voraus"

**himitsu**

Och, ich glaub nicht, daß du da der Einzige bist, mit dem MD5 Hash.

Andere Merkmale:
- Dateidatum (Erstellung/Änderung) und Dateigröße
- Versionsinfo in der Datei (zumindestens bei den EXEn und DLLs, oder wo man noch Extra-Infos aus der Datei auslesen kann, wie z.B. JPEG und MP3)

Manche gucken aber garnicht in die Datei.
Vielleicht die installierte Programmversion aus der Registry oder einer INI lesen und dann blind alles runterladen, wenn es eine neue Programmversion gibt
Wobei sich ja einige Dateien/Programme selber prüfen, z.B. über eine Signatur, so daß man selber den Hash weglassen könnte, also nur auf die Versionsinfo gucken, und den "Hash" erst zur Laufzeit prüfen lässt.

**sx2008**

Zuerst die Steuerdatei herunterladen; wenn das nicht klappt braucht man gar nicht erst weitermachen.
Dann Dateilänge vergleichen zwischen lokaler Datei und dem Wert in der Steuerdatei.
Bei Abweichung braucht man den Hash nicht mehr zu prüfen.
Hashverfahren:
* MD4 - ist schneller als MD5, kann aber leichter gefälscht werden. Bei einem normalen Updater dürfte das aber kein Problem sein
* MD5, SHA1 - für Updater gut geeignete Standardverfahren.
* SHA256 - für erhöhte Scherheit
* CRC32 - schnell, aber der Hashraum ist mit 32 Bit zu klein

Nach dem Herunterladen nochmals den Hash ermitteln um Übertragunsfehler auszuschliesen.
Alle Dateien zuerst in temporäres Verzeichnis runterladen damit man bei einem Verbindungsabbruch nicht mit einer unvollständigen Installation dasteht.
Erst nachdem alle notwendigen Dateien heruntergeladen wurden die lokalen Dateien updaten.

PS: es empfiehlt sich das Hashverfahren mit einem fremden Tool zu überprüfen.

http://www.hashemall.com/

**himitsu**

Zitat von sx2008:

Nach dem Herunterladen nochmals den Hash ermitteln um Übertragunsfehler auszuschliesen.

Wenn das übertragungsprotokoll das schon erledigt, dann wäre das unnötig.

Und das mit dem halben Update:
Es ist möglich die Datei- und Registryzugriffe in einer Transaction zu behandeln. (zumindestens im NTFS, wo sonst auch, weiß ich nicht)
Auch bietet Windows einen netten Hintergrundübertragungsdienst an, für Download/Updates, was bei größeren Programmen recht nett ist, da wird Windows gebeten die Datei zu laden und wenn sie da ist, wird das eigene Programm darüber informiert/gestartet.
Und ich finde es immer wieder krank, daß Updater sich als eigener ständig laufender Service installieren, wo doch ein Updater schöner wäre, wenn er sich als geplanter Task anmeldet, welcher z.B. einmal am Tag/Woche/Monat kurz gestartet wird, bzw. z.B. auch beim Start des Computers. (k.A. warum vorallen bei großer Software sowas nicht endlich mal durchsetzt und eventuell auch über einen gemeinsamen Updater, damit nicht jedes Programm selber nachsehn muß)

> regelmäßig und bei passenden Events starten lassen > schauen ob es ein Update und eventuell mit Installation vergleichen > wenn nichts los ist, dann gleich wieder beenden > Windows das runterladen lassen > Update-Quelldateien prüfen > Programm-Installation prüfen (Dateien korrekt und Programm eventuell nicht aktiv, falls der Updates dann nicht möglich wären) > Transaktion starten > Installation/Update starten > eventuell nochmal alles prüfen > Transaktion abschließen oder bei einem Fehler zurücksetzen > fertig

Bei einer Transaktion könnte man das vorherrige Prüfen sich auch sparen, also die Dateien nicht doppelt behandeln und einfach gleich alles machen ... bei einem Problem lässt es sich ja wieder komplett zurücksetzen und bei der vorherrigen Prüfung vergisst man sowieso bestimmt irgendeinen SonderProblemfall.

**Sir Rufo**

Updater als geplanter Task
Das diese Möglichkeit nicht genutzt wird liegt daran, dass der Updater mit Admin-Rechten laufen muss. Ein geplanter Task kann das, aber wenn das Kennwort für den Account geändert wurde, dann lief der Task nicht mehr. Neuere Versionen von Windows (ab Vista? auf jeden Fall ab Win7) haben das Problem nicht mehr.

Mal sehen, ob sich da etwas ändert, wenn XP so langsam verschwindet (verschwindet es wirklich?). Bis dahin ist das also keine empfehlenswerte Option.
Updater als Dauerdienst
Ist wohl ein Märchen, dass ein Dienst dauernd laufen muss, aber ein vernünftig geschriebener verbraucht eigentlich so gut wie keine nennenswerte Ressourcen.
Genereller Updater
Hier wäre MS eigentlich der richtige Initiator. Aber die haben doch dafür schon lange was im Säckel:
MSI-Pakete und die Gruppenrichtlinien in Verbindung mit einer Domäne. Ok, das ist eher im gewerblichen Umfeld anzutreffen und die Kontrolle hat der Domänenverwalter (was auch gut ist).

Die neueren Versionen (>Win8) haben ja jetzt auch einen AppStore und da sind Updates auch kein Problem mehr.

Ich frage mich gerade, warum hier überhaupt von einzelnen Dateien gesprochen wird und nicht von einem Setup-Paket. Nur so kann man doch gewährleisten, dass alle zusammengehörigen Teile zuverlässig ausgeliefert werden, sich an der richtigen Stelle befinden und auch alte obsolete Dateien von der Platte verschwinden. Wer Angst vor zu großen Setup-Dateien hat kann ja auch spezielle Update-Pakete schnüren (würde ich trotzdem nicht empfehlen, da idR Pflege-Aufwand und Nutzen in keinem angemessenen Verhältnis stehen). Zusätzliche Treiber, Bibliotheken, etc. können vom Setup auch noch bei Bedarf nachgeladen und installiert werden.

In dem Fall kann dann auch der Updater selber strunz-doof sein (Auf neue Version prüfen, Setup laden, Setup ausführen) und der wird auch das wildeste Update hinbekommen - weil diese Aufgabe das Setup übernimmt.

**TheMiller**

Hello!

Danke für die Antworten. Also handhaben wir das alle ähnlich/gleich. Allerdings gefällt mir die Idee mit einer "Setup"-Datei, welche die Update-Daten beinhaltet. Das erspart wirklich sehr viel Arbeit und mit Inno-Setup lässt sich ja auch viel Logik umsetzen. So kann man bequem Rollouts veröffentlichen, ohne vorher umständlich ein Update schnüren und verschiedene Dateien in verschiedene Verzeichnisse hochladen zu müssen. Ich glaube, das werde ich in Zukunft so machen.

Nur eine Frage habe ich trotzdem noch: Macht es Sinn bzw. hat es nennenswerte Vorteile, die Hashes der Programmbestandteile mit den Online-Hashes abzugleichen, oder reicht wirklich die Speicherung der Versionsnummer? Ich tue mich mit dem Gedanken schwer, die Hashes nicht zu vergleichen. Einerseits kann es sein, dass die Versions-Datei nicht den reellen Wert wiedergibt. Zudem werden Benutzer vllt. doch davon abgehalten, an den Dateien Manipulationen vorzunehmen, da sie sonst keine Updates mehr machen können. Was denkt ihr dazu?

**Namenloser**

Ich sehe persönlich nicht so den Sinn, beim Updaten die Hashes zu vergleichen. Du musst jedes mal alle Programmdateien einlesen, selbst wenn sich beim Update nur eine Datei geändert hat. Das macht den Update-Vorgang unnötig langsam und rechenintensiv.

Wenn der Nutzer unbedingt an den Dateien rumpfuschen will, dann soll er doch. Überhaupt sehe ich das eher als eigenständiges Problem an. Wenn du es wirklich verhindern willst, dass der Nutzer die Dateien verändert, dann solltest du es regelmäßig prüfen, und nicht nur beim Updaten.

**Mavarik**

Warum getrennt?
Warum als Dienst?

Eine Update.Exe als Resource mit in die Exe.
Hauptprogramm "kennt" seine eigene Version und die der DLL's

Dateien runterladen, Update.exe auf die Platte schreiben und mit Admin Rechten starten.

Mavarik

DLL-Abhängigkeiten, Versionitis usw. bleiben bei einer selbstgebauten Lösung auf der Strecke.

Man vergleicht die Hashs nicht wegen der Manipulation, sondern ob ein Update überhaupt stattfinden muss. Einige verwenden die Versionsnummer oder das Datum, aber eine allgemeine Lösung wird eben den Hash nehmen bzw. ihn anbieten. Wieso soll ich als Programmierer gezwungen sein, eine Versionsnummer einzuführen? Was ist, wenn sich die Größe nicht ändert, weil ja nur der MwSt-Satz von 19 auf 20% erhöht wurde? Was ist, wenn das Erstelldatum der Datei immer der 18.3.1963 ist, weil der Chef das so will?

**himitsu**

Zitat von Mavarik:

und mit Admin Rechten starten.

Darum nimmt man oft einen Dienst.

z.B. siehe Firefox

Der Firefox schaut nach, ob es eine neue Version gibt (anhand der Versionsnummer), läd das Setup runter und übergibt es dann an den Service, welcher standardmäßig inaktiv ist und dann manuell vom Firefox gestartet wird, falls nötig.
Der Sevice übernimmt nun das Installieren und somit ist keine Adminabfrage mehr nötig. (z.B. für Rechner, wo der Benutzer keine Adminrechte besitzt)