Explication du time de construction de la version par opposition au numéro de version, par exemple OpenSSL 1.0.1e versus h

Récemment, pour gérer les bogues SSL récemment révélés, j'ai mis à niveau ma dissortingbution Debian pure. OpenSSL signale un numéro de version de 1.0.1e qui n'est pas le dernier, mais on me dit que c'est correct, car le time de compilation rapporté par:

Version openssl -b

est le 4 juin 2014. Donc, même si la «version» est plus ancienne, je suis certain que Debian a «patché» d'une manière ou d'une autre les vulnérabilités, donc je n'ai pas vraiment besoin de la version 1.0.1h, rapiécé.

Je suppose que je ne comprends pas cela. Quelqu'un peut-il expliquer ce qui se passe? Comment suis-je censé savoir que les vulnérabilités sont corrigées si on dit 1.0.1e, pas 1.0.1h comme il se doit? Pourquoi Debian ne fait-il pas peur de mettre 1.0.1h dans la dissortingbution? Je n'ai pas compris cela.

Vous regardez probablement Debian stable, ce qui permet de garder les versions de packages stables par définition. Quelle que soit la version d'openssl qu'une version particulière d'une version stable soit celle avec laquelle elle restra. Pour les correctifs de security, les responsables de Debian rétroportent les correctifs de security en amont vers la version stable au lieu de mettre à niveau la version stable. Si vous voulez la dernière version amont de tout, alors vous aurez besoin de la twig instable.

De l' équipe de security Debian FAQ :

Q: Pourquoi manipulez-vous une ancienne version de ce package?

Le guide le plus important lors de la création d'un nouveau package qui corrige un problème de security consiste à effectuer le less de modifications possible. Nos users et nos développeurs se fient au comportement exact d'une version une fois qu'elle est faite, de sorte que tout changement que nous apportons peut éventuellement briser le système de quelqu'un. Cela est particulièrement vrai dans le cas des bibliothèques: veillez à ne jamais modifier l'interface API (Application Program Interface) ou l'interface ABI (Application Binary Interface), quelle que soit la taille du changement.

Cela signifie que le passage à une nouvelle version en amont n'est pas une bonne solution, mais que les modifications pertinentes doivent être rétroscopes. En général, les responsables en amont sont disposés à aider si nécessaire, sinon l'équipe de security Debian pourrait être en mesure de vous aider.

Dans certains cas, il n'est pas possible de rétroporter un correctif de security, par exemple lorsque de grandes quantités de code source doivent être modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version en amont, mais cela doit être préalablement coordonné avec l'équipe de security.