Debian doit fournir des paquets reproductibles

 (lists.debian.org)
1 points par GN⁺ 5 시간 전 | 2 commentaires | Partager sur WhatsApp
  • L’équipe de publication de Debian a décidé, au milieu du cycle forky, d’imposer la fourniture de paquets reproductibles
  • Le logiciel de migration bloque les nouveaux paquets qui ne sont pas reproductibles sur reproduce.debian.net
  • La migration est aussi bloquée lorsqu’une régression de reproductibilité apparaît sur un paquet déjà présent dans testing
  • L’exécution d’autopkgtest a également été ajoutée aux binNMU, comme pour les uploads source-full
  • L’ajout de loong64 et les reconstructions multi-arch ont agrandi la file d’attente CI, ce qui demande de la patience

Obligation de reproductibilité des paquets Debian

  • L’équipe de publication de Debian a décidé, au milieu du cycle de publication forky, que Debian devait fournir des paquets reproductibles
  • Cette décision s’appuie sur les efforts du projet Reproducible Builds
  • Depuis la veille, le logiciel de migration a été activé pour bloquer la migration des nouveaux paquets qui ne sont pas reproductibles sur reproduce.debian.net
  • La migration est également bloquée lorsqu’une régression de reproductibilité survient sur un paquet existant déjà dans testing

Assurance qualité et responsabilité des uploaders

  • Exécution d’autopkgtest pour les binNMU de testing

    • En début d’année, une fonctionnalité a été ajoutée au logiciel de migration pour exécuter autopkgtest aussi pour les binNMU, comme pour les uploads source-full
    • Cette fonctionnalité n’est peut-être pas directement très liée au travail de la plupart des mainteneurs, mais elle est présentée comme une étape supplémentaire vers un renforcement de l’assurance qualité

  • Ajout de l’architecture loong64 et augmentation de la file d’attente CI

    • Il y a deux semaines, la nouvelle architecture loong64 a été ajoutée à l’archive
    • Debian n’autorise la migration que des binaires construits sur les buildd et, en raison des exigences multi-arch, un grand nombre de paquets ont dû être reconstruits sur toutes les architectures
    • En raison de la fonctionnalité binNMU ajoutée précédemment, la file d’attente CI est actuellement assez importante, et l’équipe de publication demande un peu de patience

  • Suivi après l’upload

    • L’uploader du paquet source a la responsabilité de garantir que ce paquet puisse migrer
    • Si un paquet est bloqué par une régression d’autopkgtest dans une dépendance de test inverse et qu’une mise à jour de cette dépendance est nécessaire, l’uploader doit ouvrir un bug avec une gravité RC appropriée

À lire aussi

2 commentaires

 
GN⁺ 2 시간 전
Commentaires sur Hacker News

  • C’est une grande réussite pour Debian et pour le monde du logiciel libre.
    Cela dit, il a fallu pas mal de temps pour faire comprendre la nécessité de cette démarche. Quand j’ai dit sur debian-devel en 2007 qu’il fallait cela, on m’a répondu que c’était une énorme perte de temps, et en pratique il a fallu un travail colossal de nombreuses personnes pour en arriver là, mais cela en valait largement la peine.

    • Depuis 2007, il n’y a eu ni bug ni attaque que les paquets reproductibles de Debian auraient pu empêcher.
      Je ne pense donc pas qu’on puisse dire que « cela en valait la peine ». Cela ne fait qu’augmenter encore la barrière à l’entrée pour contribuer à Debian, alors qu’on voit déjà beaucoup de gens se plaindre de la difficulté d’y contribuer. Avant, on défendait cela en disant qu’« il faut toutes sortes de vérifications et de garde-fous pour que les paquets s’imbriquent correctement », mais ici cela ressemble à une difficulté supplémentaire sans raison claire, pour un bénéfice limité.

  • Il y a plus d’informations sur https://wiki.debian.org/ReproducibleBuilds. Certaines sont anciennes, mais il y a aussi des graphiques qui montrent le nombre de paquets construits en CI et, parmi eux, combien ont des builds reproductibles.
    L’orange correspond à FTBR, c’est-à-dire « échec de build reproductible ». Je ne suis pas très habitué à lire les chiffres sur ce graphique, mais j’estime cela à quelques pourcents, autour de 4 à 5 %.

    • Chez moi, ça affiche seulement ceci :

      Forbidden

      You are not allowed to access this!
      Même les balises HTML apparaissent telles quelles :)
      Édit : j’ai aussi trouvé la page « I Challenge Thee » dans l’historique. Est-ce que je me fais bloquer par une mesure anti-bot ? Pourquoi ???

  • C’est une bonne chose. NetBSD dispose de builds entièrement reproductibles depuis 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • Comme le dit aussi le lien, NetBSD y est arrivé avec l’aide de Debian. Si j’ai bien compris, ce n’est pas tant que NetBSD a travaillé plus dur, mais plutôt que le problème était plus simple. Il y a moins de paquets et moins de changements. Ils utilisent encore CVS, donc le terme « stabilité » est presque insuffisant.
      À noter que la plupart des paquets Debian ont des builds reproductibles. Ceux qui ne le sont pas, environ 5 % des paquets, sont indiqués en orange sur ce graphique : https://wiki.debian.org/ReproducibleBuilds
    • Pour me vanter un peu, stagex a été l’an dernier le premier à obtenir des builds déterministes et isolés fondés sur un bootstrap intégral depuis les sources à 100 %, et aussi le premier à exiger, à chaque release, plusieurs reproductions signées effectuées par des mainteneurs différents sur leur propre matériel.
      Debian a beaucoup progressé lui aussi, mais quand Debian dit être reproductible, cela signifie qu’il récupère des binaires tiers pour effectuer son propre build. Quand nous parlons de reproductibilité, nous voulons dire un bootstrap à 100 % depuis le code source jusqu’au bout de toute la chaîne d’approvisionnement logicielle.
      Je pense que cette différence est importante.
      https://stagex.tools

  • Je suis vraiment ravi de ce changement. Après avoir lu en 2021 à propos de l’attaque SolarWinds et avoir été choqué, je me suis impliqué dans les builds reproductibles. [1]
    Je trouve que Magnus Ihse Bursie, qui travaillait sur les builds reproductibles d’OpenJDK, l’a formulé de la manière la plus juste : « Si vous me demandez mon avis, le simple fait que les compilateurs et les outils de build aient commencé, à un moment donné, à produire des sorties non déterministes était déjà un bug dès le premier jour. » [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • Je me demande pourquoi c’est devenu un sujet maintenant. J’utilise Yocto sur des appareils embarqués, et les builds reproductibles étaient presque quelque chose qu’on pouvait mettre en place de manière évidente.
    On peut aussi activer facilement la gestion des paquets Debian, donc j’ai l’impression que tout cela était déjà possible.

    • Je me demande ce que signifie « pourquoi est-ce un sujet maintenant ».
      Les builds reproductibles sont une méthode essentielle dans l’informatique industrielle. Il ne s’agit pas tant pour Debian d’être à l’avant-garde dans ce domaine que d’adopter une pratique répandue dans l’industrie, appliquée aussi à d’autres systèmes d’exploitation utilisés pour des usages à long terme et liés à la sécurité.
      Bien sûr, une grande partie de ce que nous utilisons déjà facilement aujourd’hui vient aussi du travail difficile accompli par Yocto et par de nombreux développeurs Debian.
      Ce qui est intéressant, c’est qu’à présent les développeurs Debian appliquent cela comme une politique plus volontariste, en en faisant non plus une option mais une norme par défaut.
    • Je me demande s’ils ont effectivement vérifié de manière active que les builds sont reproductibles au bit près.

  • Pour amd64 forky :
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    Ces statistiques, ainsi que celles des autres architectures et les raisons de non-reproductibilité, sont visibles sur https://reproduce.debian.net

  • J’ai toujours trouvé surprenant que ce soit Debian qui porte cela, et non un fournisseur commercial. On pourrait penser que les grandes organisations qui paient pour RHEL et Ubuntu exigeraient fortement des binaires vérifiables.

    • Si un concurrent peut prouver que son paquet est identique au bit près à celui déployé par une grande organisation, ce concurrent peut alors profiter des garanties de sécurité de cette grande organisation.
      C’est excellent pour le logiciel libre, mais beaucoup moins pour ceux qui veulent devenir monopolistiques.
    • Les builds reproductibles existent pour réduire le besoin de confiance, mais les fournisseurs commerciaux sont dans le business de la confiance.

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
Avis sur Lobste.rs

  • C’est une bonne évolution du point de vue de la sécurité. La transition peut être pénible, mais au final cela apportera une plus grande fiabilité à tous les utilisateurs de Debian Linux dans le monde

  • Je me demande quel est l’avantage clé pour un projet comme Debian. Est-ce pour que tout le monde puisse disposer d’une preuve de l’absence de porte dérobée dans les binaires ?
    Autrement dit, est-ce que cela sert à réduire la confiance à accorder aux mainteneurs et à diminuer le risque lié à un mainteneur malveillant ? Je ne suis pas sceptique, je ne comprends simplement pas à 100 % pourquoi Debian y consacre autant de temps. Rendre une compilation reproductible semble assez compliqué et très laborieux

    • Cela permet de vérifier non seulement la présence éventuelle de portes dérobées, mais aussi toute altération ou modification plus générale. C’est utile pour la sécurité, mais aussi pour le développement du projet : des paquets construits de manière reproductible et relativement hermétique risquent moins de casser bizarrement dans l’environnement d’un autre développeur
      L’idée essentielle est de fournir un artefact prouvant que le paquet produit provient bien de ce code source précis, et non d’un second ensemble de sources caché. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      Produire des builds reproductibles est très difficile. Par exemple, les horodatages dans la chaîne de compilation peuvent introduire des différences, tout comme les métadonnées des archives générées. Il faut éliminer tous ces facteurs et, dans certains cas, il faut patcher non pas le paquet lui-même, mais des projets amont comme CMake ou le compilateur Go. Souvent, ces problèmes n’étaient même pas pris en compte auparavant, donc il faut intervenir sur toute la pile de build. Cela dit, ce travail est engagé depuis longtemps, et une grande partie de la plomberie de bas niveau est déjà terminée ou bien avancée
    • Je ne pense pas que cela doive être la priorité absolue de Debian, mais Debian ne fonctionne pas vraiment comme ça. Les gens font ce qu’ils ont envie de faire, et les priorités individuelles correspondent souvent assez mal à ce qui serait des priorités raisonnables à l’échelle du projet

  • Quand Debian parle de reproductibilité, est-ce le même concept que ce dont on parle avec NixOS ?

    • Non. NixOS is not reproducible est l’article de référence classique
    • Les distributions qui suivent les builds reproductibles comme projet tendent globalement vers le même objectif. reproducible-builds.org suit les projets qui travaillent activement sur le sujet dans leur pipeline de packaging
      NixOS travaille aussi sur les builds reproductibles et, si je me souviens bien, au moins l’ISO est 100 % reproductible à la fois au build et à l’exécution. Mais la reproductibilité dont on parle souvent à propos de NixOS n’est pas celle des « builds reproductibles » dont il est question ici. Voir le billet de foxboron lié dans un commentaire voisin de ce fil. Cela se rapproche davantage de la reproductibilité de l’environnement, ou de « builds déterministes », ce qui reste précieux, mais ce n’est pas le sujet ici

  • Pour l’instant, ça ressemble à un système à cliquet. Est-ce que les éléments qui n’ont jamais pu être construits de manière reproductible restent malgré tout autorisés ?

    • Si un paquet ne peut pas être construit de manière reproductible, il ne sera pas inclus dans la prochaine version de Debian. Autrement dit, un paquet qui « n’a jamais été construit de manière reproductible » peut rester dans Debian unstable, mais il est mal vu de conserver dans Debian unstable des paquets qui n’atteindront jamais stable. Cela dit, à ma connaissance, il n’existe pas de règle appliquée mécaniquement à ce sujet