Bonjour,
Un tel commit est un endroit rêver pour glisser une backdoor: le codereview semble complexe à gérer, ça "ne change rien" pour l'utilisateur final et tous les dev sont heureux de compiler beaucoup plus vite et donc favorable à l'idée. Loin de moins l'idée de dire que c'est le cas, qu'il y a intention de ou autre.
Ensuite, si on ne touche qu'au header, le checksum du binaire de sortie ne devrait pas changer si ?
peut importe dans quel ordre tu inclus tes .h dans tes .c
peut importe si t'ajoute des define, en retire, ajoute des prototypes (...)
Au final le compilateur se sert des .h pour aller chercher des informations qui lui sont utile à la compilation, si on a pas changé ces informations (le contenu d'un define par exemple), pas de raison que le binaire change ...
Autant je fais un tests avec un main.c a.h et b.h, quelques modifs et sha1sum et je suis sur de moi, autant sur la taille d'un noyau, je le suis moins '
# quid de la sécurité ?
Posté par domble42 . En réponse à la dépêche RFC Fast Kernel Headers très prometteur pour le noyau Linux. Évalué à 3.
Bonjour,
Un tel commit est un endroit rêver pour glisser une backdoor: le codereview semble complexe à gérer, ça "ne change rien" pour l'utilisateur final et tous les dev sont heureux de compiler beaucoup plus vite et donc favorable à l'idée. Loin de moins l'idée de dire que c'est le cas, qu'il y a intention de ou autre.
Ensuite, si on ne touche qu'au header, le checksum du binaire de sortie ne devrait pas changer si ?
peut importe dans quel ordre tu inclus tes .h dans tes .c
peut importe si t'ajoute des define, en retire, ajoute des prototypes (...)
Au final le compilateur se sert des .h pour aller chercher des informations qui lui sont utile à la compilation, si on a pas changé ces informations (le contenu d'un define par exemple), pas de raison que le binaire change ...
Autant je fais un tests avec un main.c a.h et b.h, quelques modifs et sha1sum et je suis sur de moi, autant sur la taille d'un noyau, je le suis moins '