Fedora ще приеме RPM 6 в следващата версия на Fedora 43 

rpm-fedora-43

Напредъкът по предстоящото есенно издание на Fedora (версия 43) продължава и въпреки че текущата стабилна версия (42) е само на няколко седмици, FESCo вече официално одобри няколко промени който ще бъде интегриран във Fedora 43.

RPM 6 представлява значителна еволюция спрямо предшественика си, въвеждайки поддръжка за пакети по-големи от 4 GB, модернизирани вътрешни структури, криптографски подобрения и други.

RPM 6 е нов опционален формат с поддръжка за големи пакети

Споменава се, че избраният За да направите прехода към тази нова версия на RPM, трябва да...една от най-забележителните му характеристики, което е твое възможност за обработка на пакети по-големи от 4 GB. Това техническо ограничение започваше да се превръща в проблем, особено с пакети с изходен код като Chromium, който в момента е с размер от 3,7 GB. Решението се предлага с новия формат на пакетите RPM 6, който включва полета с размер 64-бита и по-модерни вътрешни структури.

Въпреки това, Новият формат няма да бъде задължителен, тъй като като такъв, Fedora ще продължи да използва традиционния RPM 4 формат, базиран на cpio, осигуряване на съвместимост със съществуващата екосистема. RPM 6 ще може да чете и инсталира както RPM 4, така и по-нови пакети, което ще улесни плавния преход за поддържащите и производните дистрибуции.

Основният аргумент за версия 6.0 е, че RPM сигурността е въведена в новото хилядолетие. Форматът на пакета е само една част, макар и важна. Освен това, форматът е практически невидим за обикновения потребител. Основните промени, видими за крайния потребител във версия 6.0, са:

Проверката на подписа е активирана по подразбиране
Ключовете на OpenPGP се идентифицират по пълния им пръстов отпечатък, когато е наличен, и по пълния им идентификатор на ключа в противен случай.
Принудителната проверка на подписа означава, че локално компилираните пакети вече не могат да бъдат лесно инсталирани. Това е досадно за потребителите, които често правят това. Ето защо добавихме поддръжка за автоматично подписване по време на компилация. Това не е механизъм за подписване с висока степен на сигурност за разпространение на пакети; Целта е използването на локално компилирани пакети да бъде сравнително удобно, без да се жертва цялостната сигурност. Въпреки това, принудителните подписи по подразбиране могат да повлияят на някои случаи на употреба и да изискват промени.

RPM 6 подобрява сигурността със задължителни цифрови подписи и модернизирани инструменти

Преходът към RPM 6 във Fedora 43 също се очаква към важността на сигурност чрез проверка на цифрови подписи, считано от тази версия, всички пакети трябва да имат валиден подпис, който ще бъде проверен по подразбиране по време на инсталирането, добавяйки ключов слой защита срещу злонамерена намеса или повреди във веригата за доставки.

За тези, които трябва да инсталират пакети без проверка, е въведена опцията –nosignature. В допълнение към това, Поддръжката на ключове OpenPGP също е разширена, позволявайки множество подписи на пакет. Помощната програма rpmkeys също е консолидирана като основен инструмент за управление на ключове във Fedora, замествайки стария метод, базиран на gpg-pubkey. Като съвременно допълнение, Sequoia-sq, набор от инструменти, написани на Rust, е включен като алтернатива на GnuPG.

Край на една ера: сбогом на MD5, SHA1 и формата RPM 3

Струва си да се спомене, че с Въвеждането на RPM 6 бележи скъсване с остарелите технологии., тъй като поддръжката за несигурни криптографски алгоритми като MD5, SHA1 и DSA е била оттеглена, а старият формат на пакета RPM 3 е окончателно изоставен. С това Fedora прави крачка към по-стабилна, модерна архитектура на пакетите, съобразена с настоящите стандарти за сигурност.

Освен това, RPM енджинът е актуализиран, за да приема C++20 изходен код, което отваря вратата за бъдещи подобрения в производителността, поддръжка и нови функции.

Заслужава да се отбележи, че макар преминаването към RPM 6 да представлява значителна промяна, Fedora 43 ще запази традиционния формат на пакетите засега. Това позволява на общността и екипите за разработка да се адаптират постепенно, с възможност да приемат новия формат, когато са готови.

И накрая, ако сте интересувам се да науча повече за това, можете да проверите подробностите в следваща връзка.