Discussion :

[mik3.42]

Bonjour,

dans le cadre de la certification LNE de mon outil d'encaissement, je rencontre une difficulté.
Je dois prouver que certaines fonctions de mon application n'ont pas été modifiées entre la déclaration au LNE, et l'utilisation dans le programme final.

Toutes les fonctionnalités concernées sont regroupées dans une classe.
Je pensais procéder de cette manière :
- A la sortie d'une nouvelle version du logiciel, je génère un hash du fichier de ma classe que j'envoie au LNE
- Dans mon programme, j'ajoute dans une fenêtre A PROPOS, un champ contenant le hashage de ce fichier, ce dernier étant généré dynamiquement à partir de la bibliothèque de l'exécutable
Le contrôleur pourra donc aisément vérifier que les 2 hashes correspondent (hashage déclaré VS hashage dans fenêtre A PROPOS).

J'avais bêtement pensé que fExtraitRessource() me suffirait à extraire la classe dans un répertoire temporaire, pour en calculer le hashage.
Hors ce n'est pas possible...

La seule solution à laquelle je pense, serait de déporter ma classe dans un composant (interne ou externe), qui serait intégré dans mon application.
Avec ce système, je pourrai accéder au composant pour en calculer un hash.

Le problème est que ma classe tel qu'elle est codée aujourd'hui, fait appel à énormément d’élément du projet (variables, constantes, procédures globales, connexion SQL...).
ll faudrait donc réécrire une bonne partie de cette classe pour qu'elle devienne autonome.

De plus, j'utilise des transactions SQL pour lesquels une première requête viendrait du projet, et le reste du composant.
Il faudrait donc que mon objet qui communique avec la base SQL soit partagé entre le projet et le composant.

N'hésitez pas à me demander si je ne suis pas clair dans mes explications.

Merci pour votre aide.

Mike.

[frenchsting]

Bonjour,

je crois que tu as toi même répondu à la question. J'avoue que je ne travaille pas beaucoup avec les objets, mais on m'a toujours dit que ceux-ci devaient être le plus possible indépendant du projet. Je pense que pour ce que tu veux faire (ta méthode de hash), il va falloir que tu reprennes ton code.

Essaye de regarder du côté de exeinfo()/ProjetInfo() et de faire un hash dessus. Est-ce que cela pourrait te convenir ?

[mik3.42]

Bonjour,

merci pour ta réponse mais le ExeInfo() et le ProjetInfo() ne me conviennent pas.

Je pense que la seule solution est de passer par un composant.
Du coup j'ai d'autres questions :
- Faut-il utiliser un composant interne ou externe ?
- Comment partager ma variable de connexion à la base de donnée entre le projet et son composant ?
- Est-ce que je pourrai calculer un hash du composant depuis l'exe final ? parce que c'est quand même le but

Si quelqu'un à une solution sans passer par un composant je suis preneur.
Je suis audité dans 2 semaines, je suis large

[frenchsting]

Pour le choix interne/externe, regarde ici : https://doc.pcsoft.fr/?2014100

Nous utilisons des composants externes et il suffit de passer les paramètres...

Pour le hash, un conseil avant de te lancer dans des gros dév : crée un projet light, ton composant avec ta classe, fais ton code de hash, et regarde si ça te convient...

[kunnskap]

Pour apporter mon avis, je n'utilise pas de composants externes car c'est un enfer à débugger. J'ai toujours bossé avec de l'interne quasiment.
J'ignore si la génération du hash peut se faire pour un composant externe, en interne évidemment non car il s'agit d'un élément du projet comme un autre. Mais, par contre, je voudrais bien savoir comment le LNE fait pour certifier chez les autres que le logiciel validé est conforme au logiciel utilisé.

Car si ils font du dev, ils savent très bien que la version validée sera à un moment mise à jour et donc recompilée, sans qu'ils n'aient aucune maitrise des modifs qui seront faites à moins de repasser en validation à chaque maj, ce qui est infaisable pour un éditeur logiciel. Donc ça serait plutôt du...fake, d'aller dire que le logiciel ne changera pas de fonctionnel. Si l'objet à des dépendances, suffit d'en casser une pour peut être, casser le code validé.

M'enfin, la validation logicielle...

Une autre solution même si j'ignore les prérequis légaux de la validation LNE, serait d'embarquer dans le répertoire de l'exe une version de la classe utilisée en génération. Dans un genre de 7zip protégé par mot de passe ou un truc du style, mais ce serait à faire manuellement à chaque génération de l'exe (on peut l'automatiser bien sur par un script après génération dans la config du projet). Toute modif de la classe donnera un fichier dont on pourra calculer le hash et qui sera différent du hash précédent.

[mik3.42]

Bonjour et merci pour ta réponse.

Sur le principe, à chaque mise à jour logiciel, on doit fournir la signature et la version de l'exécutable.
Ce qui leur permet en cas de contrôle magasin, de valider que la version en cours d'utilisation et la dernière déclarée.
Si la mise à jour ne modifie rien de ce qui concerne la sécurité (inaltérabilité, traçage etc...), il n'y a pas de nouvelle certification à avoir.
Si des fonctions liées à la certification sont modifiées, cette nouvelle version devra d'abord être certifiée avant d'être déployée.
C'est pour cela qu'il faut arriver à bien dissocier les deux pour ne pas avoir à refaire certifier chaque mise à jour...

En ce qui concerne ta solution, je ne pense pas que ça passe à la certification.
Rien ne m’empêcherai d'avoir une classe intégrée dans l'EXE avec certaines fonctions non autorisés, qui ne sont pas dans celle qui se trouve dans le répertoire puisqu'il ne sert que pour le calcul du hash.

[niuniuk36]

Bonjour,

Si au moment de créer l’installation de ton programme, tu rajoute le fichier de ta classe "TaClasse.wdc" à celle-ci. Alors tu dois le retrouver dans ton répertoire d'installation.

Dans ton programme il te reste alors à faire le hash du fichier "TaClasse.wdc" qui est dans ton répertoire d'installation ?

Code :

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

Hash1 est un Buffer = HashFichier(HA_MD5_128, "C:\MonProjets\MaClasse.wdc")

[mik3.42]

Bonjour,

cela prouverai juste que le fichier et le hash que je leur ai fourni est le même que celui du répertoire d'installation.
Mais pas que la classe utilisée par l'EXE (qui est dans la bibliothèque et pas dans le répertoire de l'EXE) est le même fichier.

[niuniuk36]

OK je comprend mieux.

J'ai trouvé ça sur le net, pour moi ça revient un peu au même, mais ça pourrait peut être t'aider.

https://blog.infogones.com/integrati...ichierdansexe/

[mik3.42]

Merci pour ton aide.

Dans cet exemple, il intègre le fichier dans une variable de l'appli pour générer le fichier depuis l'EXE.
Mais c'est le même problème, le fichier dans la variable pourrait être différent de celui qui est exécuté...

[tidoudoux]

J'ai un peu cherché dans mes projets.

Pour le composant interne c'est mort, on ne peut pas demander à avoir un fichier indépendant.

Pour le composant externe ça devrait faire l'affaire puisqu'on a un fichier wdk à coté de l'exe. Par contre ça va demander beaucoup de réécriture, en fait si tu utilise un design patern style MVP tu peux mettre la partie MP dans ton composant et l'appeler depuis ta fenêtre (Vue).

Sinon tu colles tout dans une fenêtre et tu actives l'option "intégrer le code compilé" qui te premettra d'utiliser une fenêtre dans un fichier séparé du projet.