1 points par GN⁺ 2025-04-12 | 7 commentaires | Partager sur WhatsApp
  • Fedora pousse dans Fedora 43 un changement visant à rendre 99 % de l’ensemble des paquets reproductibles
  • Les améliorations de l’infrastructure existante ont déjà permis d’atteindre 90 %, et le plan pour le reste consiste à amener les packageurs à reconnaître ces cas comme des bugs et à les corriger
  • L’objectif est de renforcer la sécurité et d’améliorer la qualité des paquets, avec l’introduction prévue d’un outil de vérification indépendant, rebuilderd

Aperçu des builds reproductibles dans l’open source

  • Les « builds reproductibles » prennent de l’importance pour renforcer la sécurité des logiciels open source et vérifier leur intégrité
  • Un build reproductible est un build dans lequel n’importe qui peut produire exactement le même résultat à partir du même code source, du même environnement de build et des mêmes commandes de build
  • Debian a plus de dix ans d’avance dans ce domaine, et il est désormais possible d’y produire de manière reproductible même les Live CD officiels
  • Fedora a commencé à travailler sur les builds reproductibles plus récemment, mais étudie une proposition visant à rendre 99 % de tous les paquets reproductibles pendant le cycle de développement de Fedora 43

Différences entre Fedora et Debian

  • Debian autorise l’upload de paquets construits en local, ce qui peut réduire le niveau de confiance
  • Fedora construit tous les paquets de manière centralisée dans une infrastructure étroitement contrôlée
  • Fedora facilite aussi le suivi des paquets grâce à un dépôt Git appelé dist-git, qui contient les sources et les informations de hachage

La définition propre à Fedora des builds reproductibles

  • Fedora utilise une définition différente de celle de Debian
    • Les signatures et une partie des métadonnées sont exclues, l’attention portant sur le contenu réel (payload) du fichier RPM
  • La raison tient aux caractéristiques du format RPM et au mode de signature, ainsi qu’à l’inclusion d’informations comme l’heure de build (BUILDTIME) et l’hôte de build (BUILDHOST)
  • openSUSE résout ce point en définissant BUILDHOST sur reproducible

Les avancées techniques de Fedora vers les builds reproductibles

  • Depuis Fedora 38, un changement utilisant SOURCE_DATE_EPOCH a été appliqué afin de figer l’heure de modification des fichiers
  • Dans Fedora 41, un outil en Rust nommé add-determinism a été introduit pour standardiser les métadonnées des fichiers générés au build
  • Debian utilise une bibliothèque Perl appelée strip-nondeterminism, mais Fedora a choisi son propre outil afin d’éviter une dépendance à Perl
  • Jusqu’à présent, environ 90 % de reproductibilité des paquets ont été atteints

La suite du plan

  • Pour les 9 % restants, l’idée est d’amener les packageurs à considérer les problèmes de non-reproductibilité comme des bugs et à les corriger
  • L’utilitaire fedora-repro-build sera fourni pour permettre de tester en local si un build Koji est reproductible
  • Un système de vérification indépendant appelé rebuilderd doit être exploité publiquement ; il analysera les métadonnées des paquets et vérifiera leur reproductibilité via des rebuilds
  • rebuilderd peut générer des rapports de différences via diffoscope

Directives de packaging et amélioration de la qualité

  • Les directives de packaging de Fedora doivent être mises à jour en « should be reproducibly built where possible »
  • Les builds reproductibles contribuent non seulement à la sécurité, mais aussi à l’amélioration de la qualité des paquets
    • Exemple : si une dépendance matérielle est détectée dans un paquet indépendant de l’architecture, il s’agit probablement d’un bug

Cas d’exception non reproductibles

  • Haskell n’est pas reproductible lors des builds multithread, et un correctif est en cours
  • Go n’est pas reproductible car le fichier de debug .gdb_index n’est pas stable, et il n’existe pas encore de solution
  • Les signatures des modules du noyau Linux utilisent des clés temporaires, et un patch connexe a été proposé

Retours de la communauté

  • Au sein de l’équipe infrastructure de Fedora, des questions ont été soulevées sur l’emplacement et la maintenance de rebuilderd
  • La possibilité d’intégrer rebuilderd à Koji a également été discutée
  • Certains estiment aussi qu’un système distinct de Koji est préférable pour une vérification indépendante
  • D’autres proposent d’utiliser Copr à la place de rebuilderd
  • Globalement, une orientation favorisant une meilleure intégration avec les outils Fedora existants est privilégiée

Étapes à venir

  • Un ticket de proposition doit être soumis au FESCo (Fedora Engineering Steering Committee)
  • En cas d’approbation, la mise en œuvre sera réellement lancée avec comme objectif la sortie de Fedora 43 en octobre
  • Les utilisateurs finaux ne verront probablement pas une grande différence, mais c’est un changement très précieux du point de vue de la sécurité de la supply chain

7 commentaires

 
bbulbum 2025-04-14

L’équipe Fedora est toujours impressionnante et donne le sentiment que la plupart de ses décisions évoluent dans la bonne direction. J’utilise Fedora avec gratitude envers toutes les personnes qui y contribuent à chaque fois.

 
kandk 2025-04-14

J’ai l’impression qu’on l’utilisait beaucoup avant, alors pourquoi est-ce que c’est tombé dans l’oubli ces derniers temps ?

 
bbulbum 2025-04-14

Il reste encore très populaire au sein de la communauté Linux pour une utilisation comme bureau Linux.
Comme ce n’est pas une distribution destinée aux serveurs, il semble qu’elle soit peu connue dans notre pays, où l’usage du bureau Linux n’est pas très développé.

 
kandk 2025-04-14

Ah, j’ai l’impression qu’en ce moment, sauf pour les gros utilisateurs, on finit par choisir Ubuntu, qui peut servir à la fois sur serveur et sur desktop !

 
bbulbum 2025-04-14

Je suis content de voir qu’on parle de Linux, alors je me permets d’ajouter mon grain de sel.. haha
Depuis l’introduction de snap, Ubuntu a aussi perdu pas mal de soutien côté desktop.. l’environnement Unity divise beaucoup les avis.. et comme le cycle de publication est trop long, la prise en charge des pilotes récents n’est pas terrible non plus..
Si vous envisagez un Linux de bureau, je recommande vraiment Fedora.
Fedora utilise un Gnome assez proche de la version d’origine, et comme Gnome a reçu d’excellentes mises à jour récemment, j’en suis vraiment très satisfait !

 
kandk 2025-04-14

Merci haha
Ça me rappelle de vieux souvenirs de Fedora.

 
GN⁺ 2025-04-12
Commentaires Hacker News
  • Le véritable trésor, ce sont les amis qu’on rencontre en chemin
  • J’aimerais voir davantage de binaires liés statiquement. Par exemple, Python est un cauchemar à installer et à faire fonctionner
  • C’est bien de voir qu’eux aussi participent à ce projet
  • Les paquets Haskell ne sont actuellement pas reproductibles lorsqu’ils sont compilés avec plusieurs threads. Mais je ne pense pas que ce soit un gros problème. Le compilateur gcc ne prend pas en charge la compilation multithread. En C, le parallélisme vient de la compilation en parallèle de plusieurs unités de traduction
  • Je suis impressionné par ces progrès. Bravo à toutes les personnes qui y ont contribué
  • Dans les actualités connexes, en mars, les images live de Debian bookworm sont devenues entièrement reproductibles
  • En tant qu’utilisateur de Fedora, je me demande concrètement ce que cela m’apporte. Je comprends pour les builds fermés, mais je me demande pourquoi c’est nécessaire
  • La reproductibilité entre en conflit avec l’optimisation guidée par profil, en particulier lorsqu’elle implique du réseau et d’autres E/S non cohérentes
  • Oui ! J’aimerais que davantage d’outils soient déterministes. Tout en haut de ma liste de souhaits, il y a la configuration Proxmox