Il n'y a pas vraiment de rapport entre ce changement et les compilations reproductibles.
L'objectif de la compilation reproductible c'est qu'à partir d'un code source donné et quelques paramètres, on peut générer le même binaire à l'octet près quelque soit la personne qui compile.
L'intérêt est de vérifier par exemple si un paquet Debian a bien été compilé conformément au code source prétendument employé pour le générer, sans changements cachés. Ce qui est utile en cas de mainteneur malveillant ou s'il a été victime d'une attaque de sa machine par exemple.
Le but de la compilation reproductible n'est pas de vérifier si deux codes sources différents produisent le même binaire même si les changements sont très minimes fonctionnellement parlant. Pour ce genre de cas la compilation reproductible n'aidera pas : il faut analyser le correctif pour s'assurer qu'il n'y a pas d'effets de bords. Et tester, tester, tester.
[^] # Re: quid de la sécurité ?
Posté par Renault (site web personnel) . En réponse à la dépêche RFC Fast Kernel Headers très prometteur pour le noyau Linux. Évalué à 10.
Il n'y a pas vraiment de rapport entre ce changement et les compilations reproductibles.
L'objectif de la compilation reproductible c'est qu'à partir d'un code source donné et quelques paramètres, on peut générer le même binaire à l'octet près quelque soit la personne qui compile.
L'intérêt est de vérifier par exemple si un paquet Debian a bien été compilé conformément au code source prétendument employé pour le générer, sans changements cachés. Ce qui est utile en cas de mainteneur malveillant ou s'il a été victime d'une attaque de sa machine par exemple.
Le but de la compilation reproductible n'est pas de vérifier si deux codes sources différents produisent le même binaire même si les changements sont très minimes fonctionnellement parlant. Pour ce genre de cas la compilation reproductible n'aidera pas : il faut analyser le correctif pour s'assurer qu'il n'y a pas d'effets de bords. Et tester, tester, tester.