none
Générer 2 fois le même binaire RRS feed

  • Question

  • Bonjour,

    Par souci de traçabilité de mes livraison de DLL je dois pouvoir prouver que la DLL que j'ai livrée est bien le résultat de ma compilation. En d'autres termes, je dois pouvoir prouver à un auditeur que je suis capable de regénérer une dll à l'identique avec un code source donné.

    Or, lorsque je compile 2 fois le même code sous Visual studio 2008 pour générer ma dll, le fichier créé n'est jamais exactement le même (il y a 5,6 octets qui changent). Pourriez vous m'expliquer cela ? et éventuellement me dire comment pallier à ce problème.

    D'avance merci.

    Yannick.

    mercredi 16 février 2011 15:23

Réponses

  • Les octets qui changent sont le timestamp du module et il est primordial qu'il change, justement pour la traçabilité des livrables.

    En générant un timestamp à chaque compilation, il devient possible de garder le lien entre les versions des sources, les fichiers PDB ou DBG correspondant à un livrable.

    C'est un élément majeur dans une architecture utilisants des serveurs de symboles et des serveurs de sources versionnés.

    Il est ridicule de vouloir régénérer deux fois la même dll. Utilisez une SoftwareFactory (avec TFS, Hudson ou encore CruiseControl) qui en plus de générer vos dll avec un versionning automatique, posera automatiquement les label dans votre gestionnaire de code source.

    Si vous avez un esprit de paranoïaque, ces SoftwareFactory peuvent très bien être customisées pour sauvegarder vos dll générées dans votre gestionnaire de configuration logiciel (TFS, CVS, SVN etc...) en plus de les mettre à dispositions des équipes de tests depuis un partage réseau.

    En bref, soyez correctement outillé pour ne pas à avoir à résoudre de faux problèmes.


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Yannick J vendredi 18 février 2011 13:26
    jeudi 17 février 2011 00:27
    Modérateur
  • "Acheter" ? La majorité de ce type d'outillage est libre ou intégré avec les outils de développement standard d'une entreprise.

    Il faut juste de la méthode et les bons outils.

    Vous pouvez très bien générer la même dll avec des codes sources différents, timestamp près bien sûr.

    Exemple, mettre des #define non pris en compte pour un type de compilation.

    Vous pouvez aussi générer des exécutables différents avec le même code source (option de compilation, mise à jour des outils de développement, etc...)

    Vous pouvez toujours utiliser un utilitaire en post-compilation pour mettre à jours ce timestamp mais vous y perdez toute la VRAIE traçabilité, en plus de devoir refaire les signatures et autres encodages dépendant du résultat de compilation.

    Pour les organismes de certification, ils sont généralement très pointus sur les processus de génération et l'utilisation des softwareFactories s'y conforme parfaitement. Avec celles-ci, vous pouvez prouver par un processus automatique la provenance des sources, c'est bien mieux que de régénérer à l'identique une dll, ce qui ne présente aucun intérêt.

    Avec une softwareFactories ayant accès à une clé privée pour la signature des livrables, vous pouvez même avoir la non répudiabilité des livrables.

    N'interprétez pas les certifications, comprenez les.


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Yannick J vendredi 18 février 2011 13:26
    vendredi 18 février 2011 09:32
    Modérateur

Toutes les réponses

  • Les octets qui changent sont le timestamp du module et il est primordial qu'il change, justement pour la traçabilité des livrables.

    En générant un timestamp à chaque compilation, il devient possible de garder le lien entre les versions des sources, les fichiers PDB ou DBG correspondant à un livrable.

    C'est un élément majeur dans une architecture utilisants des serveurs de symboles et des serveurs de sources versionnés.

    Il est ridicule de vouloir régénérer deux fois la même dll. Utilisez une SoftwareFactory (avec TFS, Hudson ou encore CruiseControl) qui en plus de générer vos dll avec un versionning automatique, posera automatiquement les label dans votre gestionnaire de code source.

    Si vous avez un esprit de paranoïaque, ces SoftwareFactory peuvent très bien être customisées pour sauvegarder vos dll générées dans votre gestionnaire de configuration logiciel (TFS, CVS, SVN etc...) en plus de les mettre à dispositions des équipes de tests depuis un partage réseau.

    En bref, soyez correctement outillé pour ne pas à avoir à résoudre de faux problèmes.


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Yannick J vendredi 18 février 2011 13:26
    jeudi 17 février 2011 00:27
    Modérateur
  • Merci pour ces infos. Cela me donnera des arguments pour faire acheter les bons outils.

    Pour info, n'y a-t-il aucune configuration ou option pour ne pas intégrer le timestamp dans la génération de la dll ?

    Si je peux me permettre, ce n'est pas forcément ridicule de vouloir générer 2 fois la même dll... Nous sommes soumis, par des organismes de certification à devoir regénérer à l'identique des binaires à partir d'un même code source.

    Comment faire ?

    Yannick

    jeudi 17 février 2011 08:15
  • "Acheter" ? La majorité de ce type d'outillage est libre ou intégré avec les outils de développement standard d'une entreprise.

    Il faut juste de la méthode et les bons outils.

    Vous pouvez très bien générer la même dll avec des codes sources différents, timestamp près bien sûr.

    Exemple, mettre des #define non pris en compte pour un type de compilation.

    Vous pouvez aussi générer des exécutables différents avec le même code source (option de compilation, mise à jour des outils de développement, etc...)

    Vous pouvez toujours utiliser un utilitaire en post-compilation pour mettre à jours ce timestamp mais vous y perdez toute la VRAIE traçabilité, en plus de devoir refaire les signatures et autres encodages dépendant du résultat de compilation.

    Pour les organismes de certification, ils sont généralement très pointus sur les processus de génération et l'utilisation des softwareFactories s'y conforme parfaitement. Avec celles-ci, vous pouvez prouver par un processus automatique la provenance des sources, c'est bien mieux que de régénérer à l'identique une dll, ce qui ne présente aucun intérêt.

    Avec une softwareFactories ayant accès à une clé privée pour la signature des livrables, vous pouvez même avoir la non répudiabilité des livrables.

    N'interprétez pas les certifications, comprenez les.


    Paul Bacelar, Ex - MVP VC++
    • Marqué comme réponse Yannick J vendredi 18 février 2011 13:26
    vendredi 18 février 2011 09:32
    Modérateur
  • Ok, merci pour vos conseils éclairés... même si je sens une once de mépris dans vos propos...

     

    Yannick

    vendredi 18 février 2011 13:25
  • Non, non.

    Mais faites évoluer les méthodes de travail de votre entreprise. ;-)


    Paul Bacelar, Ex - MVP VC++
    vendredi 18 février 2011 14:03
    Modérateur