Discussion :

[pasqual]

Bonjour,

Je cherche à développer un updater pour mon application. J'ai vu que la question avait déjà été postée plusieurs fois mais j'avoue être encore indécie sur la marche à suivre.

La méthode à été expliquée dans ce post
http://www.developpez.net/forums/d62...r/#post3699884

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

J'ai cependant également vu qu'il existait différent programmes qui facilitait la mise à jour d'application.

Sur ce post (http://www.developpez.net/forums/d51...e/#post3087163), on parle brièvement de Updater Application Block. (Est-ce qu'il est gratuit?)

Aussi, http://www.catenalogic.com/products/...formation.aspx propose un Updater qui a l'air très complet mais qui a aussi son prix (€ 349.00). Cependant, il existe une précédante version open source du logiciel sur http://www.codeproject.com/KB/applications/updater.aspx

Je me questionne maintenant sur la stratégie à adopter:s'aider d'un de ces logiciels ou partir de zéro et suivre la démarche expliquée plus haut. Avez vous déjà une expérience avec ces logiciels, est-ce une bonne idée de partir de la version open source de codeproject?

Merci d'avance pour vos conseils

[koala01]

Salut,

Je dirais qu'il y a plusieurs réponses possibles, selon les points de vue que l'on décide d'aborder...

Il y a, par exemple, le point de vue didactique du projet...

Il ne faut en effet pas être grand clerc pour comprendre que, si tu décide d'implémenter un updater par toi-même, cela t'obligera à t'intéresser aux différents protocoles de transmission et à la gestion de processus... Ce qui, fatalement, te permettra (si tu ne t'y es encore jamais intéressé) d'évoluer un maximum, mais qui, d'un autre coté, risque d'être fort "chronophage"...

D'un autre coté, si tu te tourne vers "de l'existant", tu as de bonne chances de trouver un certain "support" pour t'aider à le mettre en oeuvre, ce sera donc moins chronophage (bien qu'il te faudra quand même peut un petit temps d'étude pour en saisir tous les principes), mais la valeur didactique est pour ainsi dire nulle

Enfin, si tu choisi cette deuxième optique, il y a l'aspect financier de la chose:

Si tu te tourne vers une solution payante, le prix de cette solution devra fatalement être "répercuté" sur les applications qui l'utiliseront...

Selon la licence sous laquelle tu décide de présenter ton application (gratuite, open-source, payante), ce peut être plus ou moins (voir pas du tout) intéressant de choisir la solution payante

Et encore faut il que tu puisse "décemment" estimer l'usage qui en sera fait: si tu sais pertinemment que tu auras de nombreuses applications (payantes) à mettre au point qui devront avoir recours à un updater, tu peux envisager plus "sereinement" le recours à une solution payante que si tu n'envisage de l'utiliser que pour une seule application.

Voilà donc une réponse de normand comme je les aime, mais j'espère qu'elle t'aura au moins apporté un éclaircissement sur les questions qu'il faut te poser

[Dreambeliever]

Salut,

la démarche plus haut n'as pas l'air si compliquée que ça.

Cependant j'ai lu le post mis en lien et il vaudrait mieux faire autrement qu'utiliser une simple somme de cryptage pour éviter de se faire hacker.

En effet, comme le dit Ram-0000:

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

Rien n'empêchera alors au faux site de donner une fausse somme de cryptage pour te faire télécharger ce que tu veux.

Un moyen simple de se prémunir de ça est d'utiliser un système de chiffrage asymétrique comme le système RSA: Tu prends un couple de clés, clé de chiffrage A et clé de déchiffrage B, tu fais connaître la clé B à tout le monde mais la clé A seulement à ton serveur. (en effet, même si le hacker connaît B, il ne peut pas en déduire A)

Quand tu veux recevoir une update, le serveur chiffre l'update via la clé A et tu la déchiffres via la clé B, et il suffit que le serveur rajoute la somme de l'update dans son message chiffré pour vérifier l'intégrité et la sécurité.

Sinon, si tu n'as pas de considérations de sécurité, un simple MD5 suffit pour vérifier que le fichier a été transmis sans erreurs ^^.

Ce que tu as à gérer, donc, c'est un simple envoi/réception sur une socket, ce n'est pas si compliqué que ça.
Après, pour vérifier si "le père meurt", il existe une solution portable:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
int compteur = 100
ofstream fichier;
 
do
{
    compteur--;
    fichier.close();
    fichier.clear();
    fichier.open("machin.exe");
    if (fichier) {
          break;
    }
    sleep(100);
} while (compteur > 0)
 
if (compteur == 0)
{
    //erreur: impossible d'ouvrir le fichier
}

En effet si le machin.exe est en cours d'exécution, tu ne peux pas écrire dans "machin.exe", et donc l'ouverture en mode écriture va bugger, et donc fichier sera à false.

[koala01]

Disons que la démarche, de son point de vue purement théorique, est effectivement simple, mais que, dans la mise en oeuvre de cette thérorie, tu peux te heurter à quelques subtilités imprévues, du fait (de manière non exhaustive)

• du besoin de sécurisation de l'updater
• de la charge potentielle du serveur
• du protocole utilisé
• de l'OS sur lequel l'updater devra tourner
• j'en passe, et de meilleures

Si tu n'es pas familier d'un de ces aspects, cela peut tout de suite devenir beaucoup moins simple

[Médinoc]

Sans compter les histoires d'élévation sous Vista : Typiquement, seul l'Updater doit avoir besoin de s'exécuter en Admin, et ne doit pas laisser la possibilité de modifier les fichiers téléchargés entre la vérification de la signature et la copie...

[koala01]

Sans compter les histoires d'élévation sous Vista : Typiquement, seul l'Updater doit avoir besoin de s'exécuter en Admin, et ne doit pas laisser la possibilité de modifier les fichiers téléchargés entre la vérification de la signature et la copie...

Ca rentre dans les "subtilités" dues à l'OS

[ram-0000]

Cependant j'ai lu le post mis en lien et il vaudrait mieux faire autrement qu'utiliser une simple somme de cryptage pour éviter de se faire hacker.

Dans mon post initial, effectivement, je propose d'utiliser un checksum signé

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

Ainsi, même si le site d'update se fait hacker et qu'il modifie le package de mise à jour, il sera incapable de signer de manière correcte la modification et la supercherie sera découverte par l'utilisateur du package d'update.

[Dreambeliever]

D'accord, je n'avais pas vu