Creation d'un updater

Version imprimable

14/10/2008, 09h41
vikki

Creation d'un updater

Bonjour à tous,

Je dois créer un updater pour un logiciel, c'est à dire que le logiciel principal se met automatiquement à jour depuis la dernière version située sur une zone commune aux utilisateurs. Jusqu'à présent, j'ai créer un exécutable séparé de mon application (appelé "update.exe") qui va chercher tous les fichiers (dll, fichiers de configuration, exécutable principal...) et dossiers de la zone commune, les compare aux fichiers de l'installation courante (une simple comparaison des dates de modification des fichiers) et met à jour les fichiers les plus récent. Cet updater se lance au démarrage du logiciel et on peut également le lancer depuis l'interface principale.

Seulement, il me semble que comparer les dates de dernière modification des fichiers est un peu foireux (sous Windows en tout cas, les dates ne correspondaient pas toujours à celles attendues). Qui plus est, certains fichiers de configuration modifiés par l'utilisateur ne doivent pas être écrasés. Existe-il une méthode générique pour mettre à jour un programme (comment font les autres logiciels)? Le plus simple n'est-il pas de supprimer toute l'installation courante et de télécharger ensuite tous les fichiers? Et comment mettre à jour l'updater?

Merci d'avance pour votre aide! ;)
14/10/2008, 09h50
Médinoc

Pour les fichiers exécutables, tu peux comparer les infos de version stockées en ressources.
Sinon, tu peux tout écraser.
14/10/2008, 10h47
koala01

Salut,

Une autre solution pourrait être de calculer la somme md5 (ou toute autre somme cryptographique à ton gout) des différents fichiers.

Par facilité, tu maintiendrait un fichier des deux cotés qui contiendrait l'ensemble de ses sommes md5.

Lorsque l'updater se lance, la première chose qu'il ferait, ce serait de comparer les sommes une à une pour déterminer quels fichiers ont été modifiés.

Après téléchargement, il pourrait d'ailleurs recalculer la somme md5 des fichiers téléchargés afin de s'assurer que le fichier n'a pas été corrompu lors du téléchargement ;)

L'énorme avantage de cette manière de travailler, c'est que le risque de collision est suffisemment faible pour t'assurer que la somme md5 sera différente à chaque modification, que c'est applicable sans restriction à tous types de fichiers, insensible aux modifications mineures due au système, et non invasif ;)
14/10/2008, 11h23
vikki

Merci pour ces réponses!

Pour la somme md5, il me semble que c'est un peu complexe (d’après Wikipedia) et que ca nécessite une lib spécialisée. Comme il s'agit d'un soft développé par et pour une entreprise, il n'y a, a priori, pas besoin d'une solution très sophistiquée, on cherche surtout quelque chose de très robuste (cela dit je garde l'idée en tête, j'avais pensé à de la comparaison bit à bit de fichiers et md5 doit être bien plus rapide :mrgreen:. De plus, j'imagine que les gros logiciels utilisent cette méthode).

Sinon, le plus simple serait effectivement de tt télécharger et écraser, en optimisant un peu (le téléchargement peu prendre du temps), genre avec un fichier texte contenant les noms des fichier à updater ou autre.

Pour la mise à jour de l’updater, le plus simple serait eventuellement de le faire à partir du logiciel lui-même, mais ca risque de devenir un gros foutoir^^

Petit rectificatif: il semble qu'un boost.md5 soit en préparation, ca simplifierait pas mal la vie...
14/10/2008, 11h30
Médinoc

Sous Windows, tu peux utiliser directement la CryptoAPI pour faire une somme MD5.
14/10/2008, 12h23
ram-0000
Dans une vie précédente, j'ai eu à faire cela, c'était un genre d'antivirus qui se mettait à jour par Internet.

La solution que nous avions adoptée était globalement la suivante:
- Le programme principal télécharge tous les fichiers nécessaires à la mise à jour dans un répertoire temporaire en vérifiant leur complétude à l'aide d'un checksum signé (utilisation de la cryptoAPI de Microsoft).
- Le programme principal met à jour (si nécessaire) le programme annexe appelé "UpdateHelper".
- Le programme principal lance le programme annexe "UpdateHelper" avec comme paramètre le process identifier du programme principal et le répertoire où sont stockés les fichiers récupérés et se suicide.
- Le programme "UpdateHelper" se lance et attend que son père meurt.
- Le programme "UpdateHelper" met à jour tous les fichiers statiques (binaires, fichier de messages, clé de registre, ...).
- Le programme "UpdateHelper" ne modifie JAMAIS les fichiers que l'utilisateur a le droit de modifier légitimement (fichier de conf, paramètres en base de registre, ...)
- Le programme "UpdateHelper" relance le programme principal et se tue.
14/10/2008, 13h09
vikki

En fait je me pose une question : pourquoi md5 dans ce cas? Pour vérifier l'intégrité d'un fichier après téléchargement? Pour comparer deux fichiers (et dans ce cas est-ce plus rapide qu'une comparaison bit à bit)? Si vous pouviez m'eclairer la dessus...

Citation:

Le programme principal télécharge tous les fichiers nécessaires à la mise à jour dans un répertoire temporaire en vérifiant leur complétude à l'aide d'un checksum signé (utilisation de la cryptoAPI de Microsoft).
Le programme principal met à jour (si nécessaire) le programme annexe appelé "UpdateHelper".
Le programme principal lance le programme annexe "UpdateHelper" avec comme paramètre le process identifier du programme principal et le répertoire où sont stockés les fichiers récupérés et se suicide.
Le programme "UpdateHelper" se lance et attend que son père meurt.
Le programme "UpdateHelper" met à jour tous les fichiers statiques (binaires, fichier de messages, clé de registre, ...).
Le programme "UpdateHelper" ne modifie JAMAIS les fichiers que l'utilisateur a le droit de modifier légitimement (fichier de conf, paramètres en base de registre, ...)
Le programme "UpdateHelper" relance le programme principal et se tue.

Je fais quelque chose qui ressemble à ca mais en beaucoup moins complet, merci beaucoup! Je vais reprendre ca (sans la vérification de complétude pour l'instant, mais ca va peut être venir).

Edit : existe-il une lib portable permettant de savoir lorsqu'un exécutable meurt à l'aide son pid (pour savoir à quel moment lancer l'exécutable suivant)? Je me contentais d'un sleep(500ms) en considérant 500ms comme suffisamment long pour que l'exécutable précédent se ferme correctement
14/10/2008, 13h31
Médinoc

Portable, ça m'étonnerait. Surtout que sous POSIX, il me semble qu'il n'est pas conseillé qu'un processus père se termine avant son fils...

Sous Windows, tu as OpenProcess(pid) + WaitForSingleObject().
14/10/2008, 13h33
poukill

Pourtant il doit bien y avoir une solution!
Mozilla Firefox en est l'exemple le plus célèbre. Les mises à jour sont dispo sous Linux et Windows, et utilisent une sorte d'updater aussi non ? :koi:
Celà dit je sais pas trop comment ça marche...
14/10/2008, 14h19
ram-0000

Citation:

Envoyé par vikki

En fait je me pose une question : pourquoi md5 dans ce cas? Pour vérifier l'intégrité d'un fichier après téléchargement? Pour comparer deux fichiers (et dans ce cas est-ce plus rapide qu'une comparaison bit à bit)? Si vous pouviez m'eclairer la dessus...

Ben le problème c'est que tu n'as pas l'original, juste une copie ramenée par le réseau. En fait tu ramènes ta copie, la signature MD5 attendue et tu vérifies si ta copie locale génère la même signature que celle que tu as ramené.

Citation:

Envoyé par vikki

Je fais quelque chose qui ressemble à ca mais en beaucoup moins complet, merci beaucoup! Je vais reprendre ca (sans la vérification de complétude pour l'instant, mais ca va peut être venir).

La vérification de complétude par signature on l'avait fait parce que on avait pas le droit de ne pas détecter un hacking de site www avec le risque alors de transmettre n'importe quoi. Imagine un peu si WindowsUpdate se fait hacker et qu'il transmet en guise de mise à jour une collection de troyens et autres virus.

Citation:

Envoyé par vikki

existe-il une lib portable permettant de savoir lorsqu'un exécutable meurt à l'aide son pid (pour savoir à quel moment lancer l'exécutable suivant)?

Non, rien de portable, c'est du spécifique OS

Citation:

Envoyé par vikki

Je me contentais d'un sleep(500ms) en considérant 500ms comme suffisamment long pour que l'exécutable précédent se ferme correctement

Mauvaise idée car si ton programme met plus de 500ms à s'arrêter (cela peut arriver si ton OS est très occupé ou si il y a plein de choses à libérer), tu ne vas pas pouvoir le mettre à jour alors que tu crois que c'est possible.
14/10/2008, 14h35
vikki

Citation:

La vérification de complétude par signature on l'avait fait parce qu’on n’avait pas le droit de ne pas détecter un hacking de site www avec le risque alors de transmettre n'importe quoi. Imagine un peu si WindowsUpdate se fait hacker et qu'il transmet en guise de mise à jour une collection de troyens et autres virus.

Ok, je comprends mieux l'intérêt maintenant. Sachant que les fichiers d'update sont stockés sur un serveur de mon employeur et que celui ci dispose de défenses en béton armé, le hackage ne devrait pas être mon problème (enfin, si les défenses sautent je vois pas trop ce que je pourrait faire de plus).

Citation:

Non, rien de portable, c'est du spécifique OS

Bon, le logiciel en question est censé être portable, va falloir utiliser du bon vieux "ifdef WIN32" (ou alors utiliser sleep(10000ms) mais les utilisateurs vont raller).

Merci pour toutes ces réponses, je vais essayer de concocter un nouvelle updater en suivant vos indications :king:
14/10/2008, 14h38
ram-0000

Citation:

Envoyé par vikki

Ok, je comprends mieux l'intérêt maintenant. Sachant que les fichiers d'update sont stockés sur un serveur de mon employeur et que celui ci dispose de défenses en béton armé, le hackage ne devrait pas être mon problème (enfin, si les défenses sautent je vois pas trop ce que je pourrait faire de plus).

Imaginons alors une attaque par DNS poisoning (ce n'est pas que théorique) et je fais croire que www.windowsupdate.com, c'est mon serveur WWW à moi et là, tu télécharges ce que je te donne sur mon site :?
14/10/2008, 15h08
vikki

Dans l'absolu tu as raison... Je ne pense pas que dans ce cas ce soit nécessaire, mais il va probablement falloir en discuter avec mon responsable, il saura où m'aiguiller. En tout cas merci pour la remarque
14/10/2008, 15h10
koala01

Personnellement, je vois deux raisons réelles d'utiliser une somme de cryptage (quelle qu'elle soit, nous sommes bien d'accord) dans un système de mise à jour.

La première est la facilité apportée à la mise à jour:

Un petit script pour créer un fichier contenant la somme de cryptage de l'ensemble des fichier (il peut éventuellement travailler longtemps, mais, comme il n'est effectué qu'avant de tout "basarder" sur le réseau, disons qu'au pire tu place tout sur le réseau quelques minutes (heures :aie:) plus tard ;))

comparer une telle somme lorsqu'elle est lue au départ d'un fichier devient des plus facile: il suffit de lire le fichier d'origine (celui qui se trouve sur l'ordinateur du client) et le nouveau (celui qui a été envoyé par le serveur) pour déterminer quels fichiers devront être mis à jour

La deuxième est qu'il ne faut jamais trop se fier aux "défenses en béton armé"...

La ligne maginot était sensée être imprenable, il n'empêche qu'elle n'a pas tenu très longtemps en 1940 ;)

De la même manière, il me semble que les américains se sont mordu les doigts à cause du béton... Ils avaient simplement demandé à leurs prisonniers de construire les murs de leur propre camps... en béton, et les prisonniers ont simplement rajouté du riz au béton, ce qui, avec le temps, l'a rendu aussi friable que des gâteaux secs.

En plus, le risque est grand de constater une baisse de l'attention sécuritaire à force de se dire que "de toutes manières, c'est inviolable".

En outre, il se peut "simplement" que la connexion utilisée crée des interférences et que le fichier ne soit pas correctement transmis dans son intégralité...

Le fait de pouvoir éventuellement vérifier rapidement si le fichier reçu correspond bel et bien à celui qu'on était sensé recevoir permet, à défaut de rajouter de la sécurité, au moins de ne pas en retirer ;)

Enfin, l'idée de la somme md5 est la première qui m'est venue à l'esprit, mais il existe de nombreux autres algorithmes, et, quand on y regarde de plus près, aucun n'est réellement difficile à mettre en oeuvre... C'est le fait de créer un algorithme capable de générer les collisions (le fait que deux fichiers différents aient la même somme) qui l'est ;)
14/10/2008, 17h40
vikki

En fait, c'est vrai que même sans considérations de sécurité, utiliser une somme de cryptage reste une manière simple de vérifier d’une part l’intégrité après téléchargement et d’autre part si un fichier nécessite une mise à jour. Hop, vendu, j’ai téléchargé crypto++ et on va testouiller tout ca. Et au moins ca m’apprendra à m’en servir.

Ok, ca marche parfaitement avec crypto++, l'updater est sur le point de naître. Merci à tt le monde et à+ :king: