{"id":123479,"date":"2025-04-12T15:05:20","date_gmt":"2025-04-12T13:05:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/utverzhdeno-obespechenie-povtoryaemyh-sborok-v-fedora-43"},"modified":"2025-04-12T15:05:20","modified_gmt":"2025-04-12T13:05:20","slug":"utverzhdeno-obespechenie-povtoryaemyh-sborok-v-fedora-43","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/utverzhdeno-obespechenie-povtoryaemyh-sborok-v-fedora-43","title":{"rendered":"Approvato il supporto per build ripetibili in Fedora 43","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Il Comitato FESCo (Fedora Engineering Steering Committee), responsabile della parte tecnica dello sviluppo della distribuzione Fedora Linux, ha approvato un progetto per garantire build ripetibili dei pacchetti nell'edizione autunnale di Fedora 43. L'obiettivo dell'iniziativa \u00e8 dichiarare la possibilit\u00e0 di applicare build ripetibili per almeno il 99% dei pacchetti nel repository. <\/p>\n
Le build ripetibili consentiranno di creare i propri pacchetti RPM, corrispondenti ai pacchetti binari pronti per il download. La corrispondenza \u00e8 garantita a livello di metadati principali e dei file inclusi nel pacchetto (differiranno solo i metadati relativi al tempo di build, all'host di build e alla firma digitale). Gli utenti potranno verificare personalmente che i file binari distribuiti nei pacchetti siano stati costruiti dai sorgenti forniti e non contengano modifiche occulte. La verifica dell'identit\u00e0 della build binaria permette di non fare affidamento solo sulla fiducia nell'infrastruttura di build della distribuzione, poich\u00e9 la compromissione del compilatore o degli strumenti di compilazione potrebbe portare all'inserimento di backdoor nascoste. <\/p>\n
Oltre alla sicurezza, le build ripetibili saranno utili anche per il controllo di qualit\u00e0: i problemi nell'ottenere build ripetibili sono spesso causati da errori o disordine nel codice, ad esempio, dall'uso di pacchetti contrassegnati come \u00abnoarch\u00bb e dipendenze legate a specifiche architetture hardware. Le build ripetibili semplificheranno anche lo sviluppo dei pacchetti: dopo piccole modifiche, i pacchetti ricostruiti differiranno solo per gli elementi direttamente legati alla modifica apportata, il che faciliter\u00e0 notevolmente il confronto delle versioni dei pacchetti e l'analisi delle modifiche. <\/p>\n
Nella formazione delle build ripetibili si tengono conto di dettagli come la corrispondenza esatta delle dipendenze; l'uso di un insieme invariato di versioni e strumenti di build; un set identico di opzioni e impostazioni predefinite; la conservazione dell'ordine di costruzione dei file (applicazione degli stessi metodi di ordinamento); disabilitazione dell'aggiunta di informazioni di servizio non costanti da parte del compilatore, come valori casuali, riferimenti ai percorsi dei file e dati sulla data e l'ora della build. Anche gli errori e le condizioni di competizione negli strumenti influiscono sulla riproducibilit\u00e0 delle build. <\/p>\n
L'infrastruttura del progetto Fedora \u00e8 gi\u00e0 pronta per realizzare build ripetibili. Ad esempio, nelle versioni precedenti, il sistema di build ha subito modifiche che sincronizzano i metadati riguardanti il tempo di modifica dei file con il codice sorgente di riferimento (mtime ora non dipende pi\u00f9 dal tempo di build), e garantiscono anche un ordine costante nell'elenco dei metadati e delle strutture nei file binari. In questa fase, la copertura delle build ripetibili \u00e8 stimata al 90%. Per garantire build ripetibili nell'ulteriore 10%, \u00e8 necessaria la partecipazione dei maintainer dei pacchetti problematici. Per incentivare la correzione di tali pacchetti, i fallimenti durante le build ripetibili saranno trattati come errori di build. <\/p>\n