A Fedora alapértelmezés szerint blokkolni fogja az aláíratlan RPM csomagokat

Segítséget kaptál? Szívesen töltöd itt az idődet? Visszajársz hozzánk? Támogasd a munkákat: Ko-fi és Paypal!

kami911 képe

A Fedora fejlesztői egy új, rendszer-szintű biztonsági változtatást javasoltak, amely szerint a jövőbeli kiadásokban — várhatóan a Fedora 44-től kezdve — az aláíratlan RPM csomagok (unsigned RPM packages) telepítését alapértelmezetten le fogja tiltani a rendszer. A cél a szoftverellátási lánc (software supply chain) biztonságának megerősítése, és az, hogy a Fedora a legújabb biztonsági szabványokhoz igazodjon.

Az új biztonsági irányelvek háttere

A Fedora és a DNF csomagkezelő (DNF package manager) már régóta megköveteli a csomagok digitális aláírásának (signature verification) ellenőrzését a hivatalos tárolókban (repositories). Maga az RPM azonban eddig nem tekintette kötelezőnek az aláírást: ha egy csomag nem tartalmazott hitelesítést, a rendszer akkor is engedte a telepítést.

Az új javaslat értelmében a Fedora átvenné az RPM 6.0 alapértelmezett beállításait, amelyek csak hitelesített, kriptográfiailag ellenőrzött aláírással (verified cryptographic signatures) rendelkező csomagok telepítését engedélyezik.

Ez a gyakorlatban azt jelenti, hogy a felhasználók nem tudnak majd aláíratlan RPM-eket telepíteni, hacsak nem tiltják le kifejezetten az ellenőrzést a --nosignature paraméterrel vagy a megfelelő API-hívással (API call).

Miért szükséges a változás?

A javaslatot jegyző Panu Matilainen, a Red Hat fejlesztője így fogalmazott:

„A hagyományos RPM ≤ 4.x viselkedése az volt, hogy ellenőrizte az aláírást, ha az jelen volt, de soha nem követelte meg. Ez a kilencvenes években talán elfogadható volt, de a mai biztonsági elvárásoknak már nem felel meg.”

Az idézet jól tükrözi a Fedora fejlesztőinek célját: a modern szoftverlánc biztonsági kockázatainak minimalizálását, különösen az aláíratlan vagy manipulált csomagokkal szemben. Az elmúlt években a Linux-ökoszisztémában is egyre nagyobb hangsúlyt kap a kriptográfiai hitelesítés (cryptographic verification) és a forráskód integritásának védelme.

Hatás a fejlesztőkre és eszközökre

A DNF5 csomagkezelő (version 5.2.14 vagy újabb) már tartalmaz egy olyan funkciót, amely csomagonként engedélyezi vagy tiltja az aláírás-ellenőrzést. Ennek köszönhetően a fejlesztők továbbra is tesztelhetnek aláíratlan csomagokat olyan eszközökben, mint a mock vagy a COPR, anélkül hogy ezek a folyamatok megszakadnának.

Az új RPM 6.0 egy másik újítása a jelszó nélküli automatikus aláírás (passwordless key signing) bevezetése, amelyet a /usr/lib/rpm/rpm-setup-autosign szkript tesz lehetővé. Ez megkönnyíti a helyben készített csomagok (locally built packages) automatikus hitelesítését, így a fejlesztők egyszerűbben tudják majd beilleszteni a biztonságos aláírási folyamatot a munkafolyamatukba.

Mit jelent ez a felhasználók számára?

A legtöbb Fedora-felhasználó számára nem lesz érzékelhető változás, mivel a hivatalos tárolók és a COPR buildjei már most is aláírt csomagokat használnak. A módosítás inkább azokat a fejlesztőket érinti, akik saját, helyben előállított aláíratlan csomagokat telepítenek. Számukra két lehetőség marad:

  • a csomagokat saját kulccsal aláírni, vagy
  • kifejezetten megkerülni az ellenőrzést a --nosignature opcióval.

Ezzel a Fedora világosan kijelöli az irányt: az aláíratlan szoftverek kivételként, nem pedig szabályként** lesznek kezelve**.

A döntés és a jövőbeli kilátások

A javaslat nyilvános visszajelzési szakaszon megy keresztül, mielőtt a Fedora Engineering Steering Committee (FESCo) elé kerülne, amely a disztribúció technikai irányvonaláért felelős testület. Ha a bizottság jóváhagyja, a változtatás a Fedora 44 részeként jelenhet meg 2026 tavaszán.

Ha azonban a döntés elhalasztásra kerül, a módosítás a Fedora 45 verzióban valósulhat meg. Mindenesetre egyértelmű, hogy a Fedora a biztonság szempontjából új korszakba lép, ahol a digitális aláírás és az integritásvédelem minden csomag esetében alapelv lesz.

A részletes javaslat a Fedora fejlesztői portálján olvasható, ahol a közösség tagjai is megoszthatják véleményüket a tervezett változtatásról.