феското, водещият технически авторитет зад разработването на Fedora, ОБЯВИ Преди няколко дни ключова промяна който ще бъде представен в есенното издание на "Fedora 43". И целта е официално одобрена осигуряват напълно възпроизводими компилации на пакети за поне 99% от хранилището.
В момента покритие на възпроизводими компилации на Fedora вече достига 90%. Останалите 10% са концентрирани в пакети, които все още изискват интервенция. от неговите поддържащи. За да се насърчи разрешаването на тези проблеми, беше решено грешките, свързани с неповторими компилации, да се третират като грешки при компилация, което ще ускори тяхното отстраняване.
Какво представляват играемите конструкции и защо са важни?
Играема конструкция гарантира, че всеки може да вземе изходния код от пакет и, използвайки същата среда, да произведе абсолютно същия двоичен файл което се предлага. Това означава, че потребителите могат да възстановят RPM пакетите и да проверят дали те съответстват на официално разпространяваните, поне във всички съответни елементи на пакета: включени файлове, основни метаданни и т.н. Единствените позволени разлики ще бъдат подробности като времеви печат, име на хост за компилация или цифров подпис.
С добавянето на игрални конструкции в Fedora 43, Проектът прави решителна стъпка към по-прозрачен модел на дистрибуция. Едно от най-непосредствените и значителни предимства на тази инициатива е, че потребителите вече няма да се налага сляпо да разчитат на инфраструктурата за изграждане на Fedora. Отсега нататък всеки ще може да провери дали разпределените двоични файлове съответстват точно на публикувания изходен код, без скрити промени или манипулации.
El Целта на проекта Fedora е амбициозна, но постижима: че поне 99% от пакетите във вашето хранилище могат да бъдат пресъздадени. В момента покритието на възпроизводимостта е вече около 90%, което показва значителен напредък. За да се покрият останалите 10%, ще е необходимо активно сътрудничество от страна на поддържащите пакети.
Като част от процеса, Fedora ще започне автоматично да отваря отчети за грешки всеки път, когато даден пакет не премине тест за възпроизводимо възстановяване. Тези отчети ще служат като директни известия за поддържащите, за да разследват несъответствията и да внедрят необходимите корекции.
Наясно сме с някои проблеми, които не могат да бъдат лесно решени:
Haskell пакетите не могат да бъдат възпроизвеждани, когато са компилирани с повече от една нишка. Екипът за разработка работи по проблема; Следващата версия на ghc може да поправи това напълно.
Пакетите mingw имат невъзпроизводими данни за отстраняване на грешки.
Пакетите на Golang имат невъзпроизводими данни за отстраняване на грешки
Ядрото използва ефимерен ключ за подписи на модули.
Подписаните от SecureBoot пакети използват частен ключ (shim, grub2).
Някои BuildRequires в SRPMs са архитектурно зависими.
Това се дължи главно на начина, по който подготвяме средата за строителство. Това не засяга директно двоичните rpm-ове.
Ще създадем система за проследяване на грешки, засягащи множество пакети (Haskell, Mingw, Golang). Надяваме се, че тези проблеми ще бъдат решени както в първоначалното, така и в последващите разработки.
Сигурност и множество предимства
Като такова се споменава, че Постигането на пълна възпроизводимост надхвърля чисто техническитеКато представляват крачка напред в сигурността позволявайки проверка дали софтуерът не е бил манипулиран по време на неговото изграждане. Но те също така имат осезаемо въздействие върху други важни аспекти на цикъла на развитие.
По отношение на контрола на качеството, процесът помага за откриването на фини грешки в пакетите. Например, ако пакет, маркиран като „noarch“ (независим от архитектурата), създава различни двоични файлове на различни платформи, това може да показва злоупотреба с хардуерно-специфични зависимости.
От гледна точка на поддръжката, Възпроизводимите компилации улесняват виждането на промените след малка редакция.- Само разликите, пряко свързани с тази модификация, ще бъдат отразени в новите двоични файлове, което ще улесни анализа, отстраняването на грешки и контрола на версиите.
Предимство за Fedora
Разработчиците на Fedora отбелязват, че постигането на възпроизводими компилации включва контролиране на множество технически фактори, като например осигуряване на последователност в зависимостите, версиите на инструментите за компилация, конфигурациите по подразбиране и реда на генерираните файлове. Компилаторът също трябва да бъде конфигуриран да не вмъква променливи стойности, като абсолютни пътища, времеви марки или случайни данни. Също така е важно да се избягват условия на състезание и скрити грешки във веригата на инструментите.
Fedora е подготвила своята инфраструктура, за да посрещне тези предизвикателства. Предишни промени в системата му за изграждане вече позволиха синхронизирането на метаданните за модификация на файлове (mtime) с тези на референтния изходен код и гарантираха, че вътрешните структури на двоичните файлове са съгласувани между изпълненията.
Накрая да вие се интересувате да научите повече за това, можете да проверите подробностите в следваща връзка.