Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Linux Enterprise Server / Guide de déploiement / Mise à jour et mise à niveau de SUSE Linux Enterprise / Code source du rétroportage
S'applique à SUSE Linux Enterprise Server 12 SP5

22 Code source du rétroportage

SUSE fait un usage intensif du rétroportage, par exemple, pour la migration des fonctions et correctifs logiciels actuels vers les paquetages publiés de SUSE Linux Enterprise. Les informations de ce chapitre expliquent en quoi comparer les numéros de version peut s'avérer trompeur dans le cadre de l'évaluation des fonctionnalités et de la sécurité des paquetages logiciels SUSE Linux Enterprise. Ce chapitre explique également comment SUSE préserve la sécurité des logiciels système et vous permet de disposer en permanence de la version la plus récente, tout en gérant la compatibilité de vos applications en plus des produits SUSE Linux Enterprise. Vous découvrirez également comment vérifier les solutions proposées réellement par le logiciel SUSE Linux Enterprise pour remédier aux problèmes de sécurité publics, ou encore comment vérifier l'état actuel de vos logiciels.

22.1 Arguments en faveur du rétroportage

Les développeurs en amont s'intéressent principalement à faire progresser le logiciel qu'ils développent. Souvent, ils combinent la correction de bogues et l'introduction de nouvelles fonctionnalités qui n'ont pas encore fait l'objet de tests poussés et qui peuvent, à leur tour, provoquer de nouveaux bogues.

Dans le cas des développeurs de distribution, il est important de faire la distinction entre :

  • les corrections de bogues avec un potentiel limité en ce qui concerne la perturbation des fonctionnalités et

  • les modifications susceptibles de perturber les fonctionnalités existantes.

D'habitude, les développeurs de distribution ne suivent pas toutes les modifications en amont lorsqu'un paquetage a intégré une distribution publiée. En règle générale, ils s'en tiennent à la version en amont qu'ils ont publiée initialement et créent des correctifs sur la base des modifications en amont afin de corriger les bogues. Cette technique est connue sous le nom de rétroportage (ou backporting en anglais).

Les développeurs de distribution ne lancent généralement une nouvelle version de logiciel que dans deux cas bien précis :

  • lorsque les modifications entre leurs paquetages et les versions en amont sont devenues à ce point importantes que le rétroportage n'est plus possible ;

  • pour les logiciels qui, par nature, vieillissent mal, comme par exemple, les logiciels de lutte contre les programmes malveillants.

SUSE fait un usage intensif du rétroportage pour qu'il soit possible de trouver un juste équilibre entre plusieurs préoccupations formulées au sujet des logiciels d'entreprise. La principale préoccupation est la suivante :

  • Disposer d'interfaces (API) stables sur lesquelles les éditeurs de logiciels peuvent compter lors de la création de produits à utiliser sur les solutions d'entreprise de SUSE.

  • S'assurer que les paquetages utilisés dans la version des produits d'entreprise de SUSE présentent une qualité optimale et ont fait l'objet de tests intensifs, tant en interne que dans le cadre du produit d'entreprise dans son intégralité.

  • Gérer les différentes certifications des produits d'entreprise de SUSE par d'autres éditeurs, telles que les certifications pour les produits Oracle ou SAP.

  • Permettre aux développeurs de SUSE de s'atteler au développement d'une nouvelle version du produit qui soit aussi bonne que possible, plutôt que de se disperser sur un grand nombre de versions.

  • Assurer un suivi clair de ce que contient une version d'entreprise particulière, de manière à ce que notre service de support puisse fournir des informations précises et opportunes.

22.2 Arguments contre le rétroportage

En règle générale, aucune nouvelle version en amont d'un paquetage n'est introduite dans nos produits d'entreprise. Il ne s'agit toutefois pas d'une règle absolue. Pour certains paquetages (notamment pour les logiciels anti-virus), les problèmes de sécurité pèsent davantage que l'approche conservatrice qui est préférable sur le plan de l'assurance qualité. Dans ce cas de figure, il arrive que des versions plus récentes soient introduites dans une version publiée d'une gamme de produits d'entreprise.

Pour d'autres types de paquetages, il arrive également que l'on opte pour l'introduction d'une nouvelle version plutôt que de recourir au rétroportage. On fait appel à cette méthode lorsque la génération d'un « backport » n'est pas possible d'un point de vue économique ou lorsque l'introduction d'une nouvelle version se justifie pleinement sur le plan technique.

22.3 Implications du rétroportage sur l'interprétation des numéros de version

En raison de la pratique du rétroportage, il est tout simplement impossible de comparer des numéros de version pour déterminer si un paquetage SUSE contient un correctif pour un problème spécifique ou si une fonctionnalité donnée y a été ajoutée. Avec le rétroportage, la partie en amont du numéro de version d'un paquetage SUSE indique simplement la version en amont sur laquelle il est basé. Le paquetage peut contenir des correctifs de bogue et des fonctionnalités qui ne figurent pas dans la version en amont correspondante, mais qui ont fait l'objet d'un rétroportage.

Lorsque le rétroportage est appliqué, cette valeur limitée de numéros de version peut occasionner des problèmes au niveau des outils d'analyse de la sécurité. Certains outils de recherche des vulnérabilités en matière de sécurité (ou des tests spécifiques réalisés par ces outils) opèrent uniquement sur les informations de version. Ces outils et tests ont donc tendance à générer des « faux positifs » (lorsqu'un logiciel est faussement identifié comme vulnérable) en cas de rétroportage. Lors de l'évaluation des rapports issus d'outils d'analyse de sécurité, vérifiez toujours si une entrée est basée sur un numéro de version ou sur un test de vulnérabilité réel.

22.4 Comment vérifier les bogues qui ont été corrigés et les fonctionnalités qui ont fait l'objet d'un rétroportage et qui sont disponibles ?

Les informations relatives aux correctifs et fonctionnalités ayant fait l'objet d'un rétroportage sont stockées à plusieurs emplacements :

  • Journal des modifications du paquetage :

    rpm -q --changelog name-of-installed-package
    rpm -qp --changelog packagefile.rpm

    La sortie documente brièvement l'historique des modifications du paquetage.

  • Le journal des modifications du paquetage peut contenir des entrées telles que bsc#1234 (« Bugzilla SUSE.C.om ») qui font référence à des bogues sur le système de suivi SUSE Bugzilla ou des liens vers d'autres systèmes de suivi. Il se peut que vous ne puissiez pas accéder à l'ensemble de ces informations en raison des politiques de confidentialité en vigueur.

  • Un paquetage peut comporter un fichier /usr/share/doc/NOM_PAQUETAGE/README.SUSE contenant des informations générales et de haut niveau spécifiques au paquetage SUSE.

  • Le paquetage source RPM contient les correctifs qui ont été appliqués lors de la création des RPM binaires ordinaires sous la forme de fichiers distincts qu'il est possible d'interpréter si vous êtes rompu à la lecture de code source. Reportez-vous au Section 6.1.2.5, “Installing or Downloading Source Packages” pour installer des sources de logiciels SUSE Linux Enterprise, consultez le Section 6.2.5, “Installing and Compiling Source Packages” pour créer des paquetages sur SUSE Linux Enterprise et consultez le site Maximum RPM (RPM maximum) pour connaître le fonctionnement interne des versions des paquetages SUSE Linux Enterprise.

  • Pour les correctifs des bogues de sécurité, consultez les annonces de sécurité de SUSE. Les bogues sont généralement désignés par des noms standard, tels que CAN-2005-2495, dont la gestion est assurée dans le cadre du projet CVE (Common Vulnerabilities and Exposures).