Toujours retraductible

(retranslated) le sera. Pour aider à  comprendre la réponse, revoyons comment le code objet est généré sous l’OS/400. En partant du code source, le compilateur construit des « modèles de création ». Le traducteur (translator) au-dessous de l’interface machine traduit les modèles de création dans le code objet approprié. (A un très haut niveau, les modèles de création sont analogues aux codes byte de Java.) Avant la V5R1, le fait de supprimer l’observabilité supprimait le code source et les modèles de création. Depuis la V5R1, le fait de supprimer l’observabilité des exécutables compilés sur la V5R1 (ou les releases à  venir) supprime encore le code source – mais pas les modèles de création. Cela est parfois appelé « always retranslatable » (toujours retraduisible). On peut également utiliser le paramètre force object conversion (FRCOBJCVN *REQ *ALL) sur les commandes RSTLIB (Restore Library), RST -Restore), RSTOBJ (Restore Object), et RSTLICPGM (Restore Licensed Program) pour accomplir la même chose.

   Comment cela est-il possible ? Dans les programmes pré-V5R1 livrés avec observabilité, le code objet pouvait être retraduit. Mais, le fait de supprimer l’observabilité rendait la retraduction impossible. Il y a quelques bonnes raisons pour supprimer l’observabilité.

   Premièrement, on réduit l’exécutable livré, économisant ainsi de l’espace disque et du temps de transfert. Deuxièmement, on aide à  protéger la propriété intellectuelle du fournisseur – parce que sans le code source, le reverse engineering devient beaucoup plus difficile.

   Mais en quoi cela améliore-t-il la sécurité ? Une propriété du traducteur dans SLIC (System Licensed Internal Code) est qu’il ne génèrera pas du code susceptible de contourner l’intégrité ou la sécurité du système. La retraduction remplace le code objet existant par un nouveau code objet dont on est sûr qu’il suit les règles. Donc, si un fournisseur altère un exécutable puis vous l’envoie, le fait de retraduire cet exécutable supprime toutes les altérations. Si l’exécutable n’a pas été altéré, son comportement ne changera pas. Mais s’il a été altéré, son comportement sera ou ne sera pas conforme à  ce que vous attendiez, selon la nature de l’altération.

   Le message à  retenir ici est que si vous configurez le système pour toujours retraduire les exécutables, et si un fournisseur d’applications vous dit de mettre cette valeur à  zéro ou continue à  livrer du code compilé avant la V5R1, vous devez vous interroger sur ses motivations.

   De plus, garder les modèles de création ne pose aucun problème quant à  la protection intellectuelle du logiciel. S’il est possible de pratiquer le reverse engineering sur les modèles de création, ce n’est ni plus facile ni plus difficile que de pratiquer le reverse engineering sur le code objet lui-même.

   La conservation des modèles de création procure aussi un avantage important, non lié à  la sécurité. Si IBM décide de changer de matériel à  nouveau, le processus sera beaucoup plus facile pour des exécutables compilés en V5R1 ou supérieure, parce que le système n’aura pas besoin d’observabilité pour convertir les exécutables afin qu’ils fonctionnent sur le nouveau matériel.

   On pourra constater que les programmes compilés en V5R1 avec l’observabilité supprimée seront plus grands que les mêmes programmes compilés en pré-V5R1 avec l’observabilité supprimée. La différence de taille dépend beaucoup du code spécifique mais elle peut aller d’un petit pourcentage jusqu’à  30 % de plus pour des programmes utilisateur. Rappelons que la taille n’est supérieure que pour des exécutables dont l’observabilité a été supprimée. IBM considère que la sécurité et la future souplesse importantes découlant de ce changement, compensent largement la croissance de la taille de l’objet.

   Comme avec la valeur système QVFYOBJRST, méfiez-vous des fournisseurs qui demandent de mettre QFRCCVNRST à  0, sans donner de raison valable – particulièrement si la raison vous est inconnue. Cela signifie probablement que le fournisseur ne veut pas que vous retraduisiez son code. Demandez aussitôt pourquoi.

   Enfin, sachez que la retraduction d’un exécutable supprime toute signature existante. Si vous connaissez le fournisseur de l’exécutable et lui faites confiance, vous avez deux choix. Premièrement, vous pouvez mettre QFRCCVNRST à  0 au moment de l’installation de l’application de ce fournisseur. Ce faisant, vous conservez la signature du fournisseur et pouvez vérifier périodiquement si quelqu’un à  l’intérieur de la société a altéré l’exécutable. Le second choix consiste à  restaurer périodiquement l’application de ce fournisseur et à  forcer la retraduction à  chaque fois. Quelle que soit la méthode, si le fournisseur est digne de confiance, vous devriez être en sécurité.