Der Sprung zu RPM 6.0 markiert ein Vorher und Nachher im am weitesten verbreiteten Paketmanager im Ökosystem von Red Hat Enterprise Linux, SUSE und Derivate. Diese Version vereint jahrelange Arbeit zur Modernisierung von Sicherheit, Paketformaten und Tools und ist in jedem Bereich des Projekts sichtbar. Wenn Sie Systeme verwalten oder Software verpacken, ist diese Änderung für Sie wichtig, da sie sich auf die Erstellung, Signierung, Überprüfung und Installation von Paketen auswirkt.
Die Veröffentlichung erfolgte am 22. September 2025 und folgt einem Kandidaten, der nun endgültig als finale Version bestätigt wurde. Neben der öffentliche Bekanntmachung, es gibt einen großen Aufwand in der Dokumentation und Änderungen des Standardverhaltens. RPM 6.0 Führt Unterstützung für das neue v6-Format ein und stärkt die kryptografische Verifizierung, während die Unterstützung für v4-Pakete beibehalten und die Installation von v3 vermieden wird.
Was ist RPM 6.0 und warum ist es wichtig?
Mit RPM 6.0 konsolidiert das Projekt sicherere Signaturverfahren, macht veraltete Algorithmen überflüssig und ebnet den Weg für ein Paketformat, das für moderne Größen und Metadaten geeignet ist. Das v4-Format wird 25 und die Codebasis nähert sich ihrem 30. Jubiläum., daher war diese umfassende Überarbeitung notwendig, um es an die aktuellen Standards und die Größe zeitgenössischer Repositorien anzupassen.
Die offizielle Ankündigung hebt Meilensteine wie die OpenPGP-Mehrfachsignaturverwaltung, die Unterstützung von OpenPGP v6-Schlüsseln und -Signaturen (einschließlich Post-Quanten-Kryptografie) und die Einführung von Strategien zum Erhalt makelloser und überprüfbarer Release-Tarballs hervor. Das Hauptziel besteht darin, die Sicherheitslatte höher zu legen, ohne die Kompatibilität zu beeinträchtigen. im Alltag von Packern und Administratoren.
Downloads und Footprints
Die Distribution enthält die Hauptquelldatei rpm-6.0.0.tar.bz2 sowie die SHA256-Prüfsumme zur Integritätsprüfung. SHA256: 14abb1b944476788d90005d8d61d5d30fce80d9f0de11eb657b14e5c9ef27441.
Übersicht der Änderungen gegenüber 4.20.1
- Unterstützung für v4- und v6-Pakete, mit ausführlichen Kompatibilitätshinweisen.
- Mehrere OpenPGP-Signaturen pro Paket und Unterstützung für OpenPGP v6- und PQC-Schlüssel.
- Aktualisieren Sie zuvor importierte Schlüssel und verwenden Sie während des gesamten Zyklus den vollständigen Fingerabdruck oder die vollständige ID.
- Das Installationsprogramm für das Paket v3 wird eingestellt. Es kann mit rpm2cpio angezeigt und extrahiert, aber nicht installiert werden.
- Standardmäßig wird die Signaturüberprüfung strikt durchgesetzt, was die Sicherheit des Ökosystems erhöht.
- Umfassende Überarbeitung der Manpages und Dokumentation mit versioniertem Inhalt auf der offiziellen Website.
- Makellose und überprüfbare Release-Tarballs, wodurch die Reproduzierbarkeit und die Prüfbarkeit gestärkt werden.
Änderungen und Verbesserungen für den allgemeinen Gebrauch
Das Dienstprogramm rpmkeys gewinnt bei der Schlüsselverwaltung erheblich an Bedeutung: Ermöglicht jetzt die Aktualisierung von Schlüsseln mit rpmkeys –import (einschließlich der Aktualisierung der mehrdeutigen Kurzkennung auf einen vollständigen Fingerabdruck), Importieren aus einer Pipe, Exportieren mit rpmkeys –export und konsistentes Arbeiten über verschiedene Schlüsselbund-Backends hinweg. Darüber hinaus können mit rpmkeys –rebuild Schlüsselbundinhalte neu erstellt und zwischen Backends migriert werden, und bei der Schlüsselsuche wird jetzt die Groß-/Kleinschreibung nicht mehr beachtet.
Auch rpmsign macht einen Sprung: Es kann mit GnuPG oder Sequoia-sq signiert werden Gesteuert wird dies über das Makro %_openpgp_sign. Der Unterbefehl rpmsign –addsign ersetzt keine vorhandenen Signaturen mehr; standardmäßig fügt er v6-Paketen beliebig viele Signaturen hinzu, bei Verwendung von –rpmv6 auch v4-Paketen. RPMsign –resign hingegen ersetzt alle bisherigen Signaturen durch eine neue.
Bei Abfragen werden Tag-Erweiterungen wie rpmformat (herausfinden, ob es sich um v3, v4 oder v6 handelt) und openpgp (Verwaltung aller OpenPGP-Signaturen) hinzugefügt. Der :hashalgo-Formatierer wurde hinzugefügt um Hash-Algorithmusnamen anzuzeigen, und der Alias –filemime scheint die MIME-Abfrage nach Datei durchzuführen. Die Terminologie ist für alle Nachrichten standardisiert: OpenPGP wird durchgängig verwendet und v3-Header- und Payload-Signaturen werden als veraltet gekennzeichnet.
Neue Berechnungsfunktion und Fehlerbehebungen in RPM 6.0
Eine neue Funktion berechnet während der Überprüfung einen konfigurierbaren Satz von Zusammenfassungen und speichert sie in der RPM-Datenbank, um die Identifizierung der Quellpaketdatei zu erleichtern. Mehrere Betriebsprobleme gelöstScriptlet-Fehler wirken sich jetzt auf Transaktionsergebniscodes aus; bestimmte fehlgeschlagene Trigger wirken sich auf zugehörige Vorgänge aus; und Probleme mit –hash, –percent und –test in Verbindung mit –restore wurden behoben.
Fehler wie ein Segmentierungsfehler und Lecks in rpmgraph, dem von rpm2archive für tar und cpio verwendeten Suffix, wurden behoben und eine umfassende Neufassung der Manpages vorgenommen: Einheitlicher Stil mit Beispielen, neue Seiten für Komponenten und Formate, wobei Benutzerbefehle in Abschnitt 1 verschoben wurden und bisher nicht dokumentierte Aspekte behandelt wurden. Die versionierte Dokumentation auf der offiziellen Website umfasst Manpages, ein Referenzhandbuch und eine API.
Verpackung und Verpackungsbau
rpmbuild kann jetzt zwei verschiedene Formate generieren, die durch das Makro %_rpmformat gesteuert werden (Werte 6 oder 4). Darüber hinaus ist die Selbstsignierung im Build aktiviert Wenn %_openpgp_autosign_id definiert ist und das Tool rpm-setup-autosign hinzugefügt wird, um diese Konfiguration zu erleichtern.
In Makros wird %{span:…} hinzugefügt, um mehrzeilige Definitionen zu ermöglichen, und %{xdg:…} wird hinzugefügt, um XDG-Basispfade auszuwerten. Unterstützung für die E2K-Architektur wurde hinzugefügt und eine Reihe von Korrekturen: Quellreihenfolge und Patches im Header, Lua-Glob, der das C-Argument berücksichtigt, Architekturvalidierung am richtigen Punkt, Akzeptanz von Build-System-spezifischen %prep-Abschnitten und Korrekturen in Check-Rpaths, wenn RPATH und RUNPATH koexistieren.
Behebt einen Speicherverlust in rpmspec –shell, eine 4.20-Regression in rpmbuild -rs mit nicht vorhandenen Verzeichnissen und eine zusätzliche neue Zeile in rpm –eval. Ein Segmentierungsfehler wurde ebenfalls behoben. im Falle einer ungültigen Ausgabe vom Abhängigkeitsgenerator im Multimodus, und die brp-selfperms-Richtlinie wurde entfernt. Schließlich wurde der veraltete Schalter –nodirtokens von rpmbuild entfernt.
API-Änderungen
Im Schlüsselbundbereich werden Funktionen zum Iterieren und Verwalten von Schlüsseln hinzugefügt: rpmKeyringInitIterator, rpmKeyringIteratorNext, rpmKeyringIteratorFree, rpmKeyringVerifySig2, rpmKeyringLookupKey und rpmKeyringModifyFür rpmPubkey werden Zugriffsmethoden wie rpmPubkeyFingperint, rpmPubkeyFingerprintAsHex, rpmPubkeyKeyIDAsHex und rpmPubkeyArmorWrap sowie rpmPubkeyMerge hinzugefügt, um Deskriptoren desselben Schlüssels zusammenzuführen.
Für den permanenten Transaktionsschlüsselbund sind rpmtxnImportPubkey, rpmtxnDeletePubkey und rpmtxnRebuildKeystore enthalten. Der rpmSign-Vorgang wird mit neuen Flags gesteuert: RPMSIGN_FLAG_RESIGN, RPMSIGN_FLAG_RPMV4 und RPMSIGN_FLAG_RPMV6. rpmteVfyLevel und rpmteSetVfyLevel sowie ihre Entsprechungen te.VfyLevel und te.SetVfyLevel wurden ebenfalls zu den Python-Bindungen hinzugefügt.
Bei mehreren Signaturen erscheinen Kennungen wie RPMTAG_OPENPGP, RPMSIGTAG_OPENPGP (Alias der oben genannten) und das Verifizierungsflag RPMVSF_NOOPENPGP. Neue Etiketten werden hinzugefügt: RPMTAG_PAYLOADSIZE, RPMTAG_PAYLOADSIZEALT, RPMTAG_RPMFORMAT, RPMTAG_FILEMIMEINDEX, RPMTAG_MIMEDICT, RPMTAG_FILEMIMES, RPMTAG_SOURCENEVR, RPMTAG_PAYLOADSHA512, RPMTAG_PAYLOADSHA512ALT, RPMTAG_PAYLOADSHA3_256, RPMTAG_PAYLOADSHA3_256ALT, RPMTAG_SHA3_256HEADER.
Es gibt umbenannte Tags: RPMTAG_PAYLOADDIGEST wird zu RPMTAG_PAYLOADSHA256 verschoben, RPMTAG_PAYLOADDIGESTALT wird zu RPMTAG_PAYLOADSHA256ALT verschoben und RPMTAG_PAYLOADDIGESTALGO wird unter RPMTAG_PAYLOADSHA256ALGO als veraltet markiert. SHA-3-Kennungen werden hinzugefügt: RPM_HASH_SHA3_256 und RPM_HASH_SHA3_512 sowie MIME-bezogene Symbole pro Datei in v6-Paketen, wie z. B. rpmfilesFMime und rpmfiFMime, und das Flag RPMFI_NOFILEMIME.
Im OpenPGP-Bereich werden RFC 9580-konforme Kennungen und die Funktion pgpDigParamsSalt hinzugefügt, um das Pre-Salt von v6-Signaturen abzurufen. Für Digest-Bundles wird rpmDigestBundleUpdateID angezeigt. (aktualisiert einzelne Kennungen). Weitere neue Funktionen: rpmtsAddInstallElement gibt 3 für nicht unterstützte Formate zurück und fdSize meldet einen Fehler für nicht reguläre Dateien.
Mejoras Internas
RPM-Code wird auf C++20 verschoben (mit Ausnahme von Python-Plugins und -Bindungen). Schriftarten werden in .cc und .hh umbenannt, dynamische Strukturen werden nach STL migriert und die Referenzzählung durch atomare Operationen verstärkt. Darüber hinaus wird die Testsuite erweitert und die Testerstellung vereinfacht.
Es werden eine echte Schlüsselbundabstraktion und ein experimentelles Backend basierend auf openpgp.cert.d eingeführt. Build-Make-Site-Ziel hinzugefügt um lokale Dokumentation zu rendern, und das Testbild passt sich an die Toolbox an. Unterstriche sind in RPMTAG-Namen zulässig, und Regressionen wurden behoben, wie z. B. die reservierte Größe für Signaturen und der Alternativenmechanismus, der Signaturen stört.
Behoben: Schlüsselbund-Lesevorgänge ohne Transaktionssperre, ein Race Condition in rpmioMkpath, Rekursionstiefe in Makro-Fehlermeldungen und ein Fall, in dem leere Passwd- oder Gruppenfelder dazu führten, dass Einträge ignoriert wurden. Interne Makros sind vor dem Laden von Dateien wieder verfügbar, der fdSize-Fehler in rpmSign wird korrekt behandelt, Pseudo-Tags werden in –querytags bereinigt und das Installationspräfix wird in den alten Skripten „find-provides“ und „find-requires“ beachtet.
Weitere interne Verbesserungen
Außerdem wurden dateibezogene Referenzlecks in Python behoben, die Abhängigkeitsspeicherung stabilisiert, um Nichtdeterminismus zu vermeiden, das Chroot-Escape im Sysusers-Skript mit u!-Einträgen behoben und eine 4.19-Regression in fehlgeschlagenen Update-Rückgabecodes behoben. Warnung vor Makrodateien in rpmrc, die Transaktionssperre wird nach –rebuilddb neu erstellt, stellt sicher, dass gpg(keyid) aus gpg-pubkey entfernt wird und Symbole, die versehentlich an die ABI durchgesickert sind, werden bereinigt.
Nicht portable Verwendungen von Signalen wurden entfernt, die RPMlog-Sperre wurde optimiert und Python-Bindungen unterstützen die Modulisolierung für mehrere Unterinterpreter und beheben Ressourcenlecks mit ASAN-Tests. Es handelt sich um Verbesserungen, die die Robustheit, Portabilität und Wartbarkeit verbessern. an allen Fronten.
Voraussetzungen für die Kompilierung von RPM
Zusätzlich zu C99 ist nun ein C++20-Compiler erforderlich; eine Unterstützung des C++20-Moduls ist nicht erforderlich. Zum Erstellen mit Sequoia ist rpm-sequoia 1.9.0 oder höher erforderlich (und ist die Standardoption), Python 3.10 oder höher für Bindungen und der Scdoc-Generator für Manpages.
Vorkompilierte API-Dokumentation ist nicht mehr in Release-Tarballs enthalten; die Erstellung ist mit Doxygen optional. Vorgefertigte APIs pro Version sind verfügbar im FTP des Projekts.
RPM 6.0-Kompatibilität und Format-Keynotes
Das Paketformat v6 bietet eine 64-Bit-Dateigröße und die damit verbundenen Beschränkungen sowie eine kryptografische Modernisierung durch die Entfernung von MD5 und SHA1, SHA3-256-Hashes im Header und SHA512- und SHA3-256-Digests in der Nutzlast. MIME-Informationen werden pro Datei hinzugefügt, und es gibt umfassende Unterstützung für RPM ab 4.14 (mit Nuancen). Der externe Abhängigkeitsgeneratormodus wird in v6 nicht mehr unterstützt und ältere rpmlib-Abhängigkeiten vor 4.6 wurden entfernt, um Störungen zu beseitigen.
v6-Pakete können mit RPM ab 4.6 ausgecheckt, mit 4.12 entpackt und mit 4.14 oder höher überprüft und installiert werden, vorbehaltlich bekannter Einschränkungen. v4-Pakete werden weiterhin vollständig unterstützt Die von 6.0 generierten Pakete sind identisch mit denen des 4.x-Zweigs. In der Standardkonfiguration werden Pakete, die mit RPMs unter 4.14 erstellt wurden, jedoch nicht verifiziert, da sie schwache Digests verwenden. Sie können %_pkgverify_level auf signature setzen, um diese Digests zu ignorieren, oder das 4.x-Verhalten wiederherstellen, indem Sie %_pkgverify_flags auf 0 setzen, wenn eine schwache Digest-Verifizierung erforderlich ist.
Die v3-Installation wird entfernt, kann jedoch mit rpm2cpio angezeigt und extrahiert werden. Standardmäßig erstellt RPM v6-Pakete; dies kann rückgängig gemacht werden, indem %_rpmformat auf 4 gesetzt wird. In Paketen, die mit RPM 6.0 oder höher erstellt wurden, ist die Lua-Familie posix.fork deaktiviert, während sie in Paketen, die mit 4.20 oder früher erstellt wurden, weiterhin funktioniert.
Weitere Überlegungen: Die Konfiguration des Signaturschlüssels wird jetzt mit %_openpgp_sign_id definiert (Abwärtskompatibilität mit %_gpg_name), Signaturmakros auf niedriger Ebene werden parametrisch und benutzerdefinierte %__gpg_sign_cmd-Überschreibungen funktionieren nicht mehr sofort. %_passwd_path und %_group_path dürfen durch Doppelpunkte getrennte Listen sein. um mehrere NSS-Quellen zu verwenden, und die Abfrageschalter –pkgid und –hdrid wurden entfernt.
RPM 6.0 und Fedora 43: Umfang, Vorteile und Tests
Das Upgrade auf RPM 6.0 in Fedora 43 Ziel ist es, die Sicherheit zu erhöhen und den Weg für das v6-Format zu ebnen, ohne das neue Format jedoch bereits als Standard zu übernehmen. Fedora 43 wird weiterhin standardmäßig v4 generieren., und die strikte Durchsetzung der Signaturüberprüfung wird als Systemänderung in einer zukünftigen Version behandelt.
Zu den wichtigsten Vorteilen für Fedora gehören: OpenPGP-Schlüssel werden jetzt immer per Fingerabdruck oder vollständiger ID identifiziert, sie können mit rpmkeys-import aktualisiert werden, mehrere Signaturen pro Paket werden unterstützt, lokale Selbstsignierung wird während Builds unterstützt und die Verwendung von Sequoia-sq als Alternative zu GnuPG. Es erleichtert auch das Testen des v6-Formats im Ökosystem ohne seine weltweite Einführung zu erzwingen.
Nicht im Umfang enthalten: allgemeine Migration von Fedora zum v6-Format oder Änderung des Standardüberprüfungsmodus. Changemaker sind für die Überschreitung der Drehzahl verantwortlich und bei Inkompatibilitäten helfen, während die übrigen Entwickler testen, Probleme melden und bei Bedarf Tools von Drittanbietern anpassen müssen.
Auswirkungen auf Upgrade und Kompatibilität: Aufgrund des neuen Schlüsseladressformats und signaturbezogener Ausgabeänderungen müssen Skripte und Tools von Drittanbietern möglicherweise angepasst werden. Für frühzeitige Tests Es wird empfohlen, Folgendes zu validieren: Aktualisieren importierter Schlüssel, Schlüsselbundverwaltung mit rpmkeys und Kompatibilität des v6-Formats mit externer Software (Erstellen mit %_rpmformat auf 6).
RPM 6.0-Benutzererfahrung auf Fedora
Benutzererfahrung: Die Signatur- und Schlüsselausgabe ist auf Groß- und Kleinbuchstaben standardisiert und die Schlüssel werden per Fingerabdruck oder vollständiger ID angezeigt, wodurch die alte, kollisionsanfällige Kurz-ID aufgegeben wird. rpmkeys ist als offizielles Tool etabliert um den Schlüsselbund zu manipulieren; alte Methoden wie das manuelle Berühren von GPG-Pubkey-Pseudopaketen sind veraltet und sollten auf RPMkeys oder die neuen APIs migriert werden.
Abhängigkeiten: Der SOName ändert sich nicht, daher sind keine Abhängigkeitsneuerstellungen erforderlich; es bestehen keine Abhängigkeiten von anderen Fedora-Änderungen. RPM ist als C++ erstellt und fügt daher eine Laufzeitabhängigkeit von libstdc++ hinzu. Für die Signierung mit Sequoia ist Sequoia-sq 1.0 oder höher erforderlich. als optionale Abhängigkeit und betrifft nur die Paketsignierung.
Notfallplan: Bei Bedarf auf RPM 4.20 zurückgreifen, mit einer Frist für den Beta-Freeze, ohne die Veröffentlichung zu blockieren. Die Auslieferung wird fortgesetzt, obwohl das v6-Format noch nicht der Standard ist im Vertrieb.
RPM 6.0 Versionshinweise und Hintergrundankündigung
Der vorherige Kandidat enthielt Fehlerbehebungen und Aktualisierungen der Manpage und wurde in die Endfassung befördert. Die vom RPM-Team unterzeichnete Ankündigung Es wird hervorgehoben, dass seit dem Neustart von rpm.org um das Jahr 2007 auf diesen Meilenstein hingearbeitet wurde, mit Meilensteinen wie 64-Bit-Dateigrößen, steckbaren Abhängigkeitsgeneratoren, Transaktions-Plugins, umfangreichen Abhängigkeiten, Dateitriggern, Verbesserungen der Debuginformationen, neuen Datenbank-Backends, Lua-Integration und Makroausdrücken, dynamischen Build-Anforderungen, Spezifikationsgenerierung, Benutzer- und Gruppenunterstützung sowie deklarativen Build-Systemen.
Über 300 Personen haben Code aus mehreren Distributionen und Organisationen beigesteuert. Die Geschichte des Projekts und seiner Community erklärt die Stabilität und den Umfang die RPM 6.0 übernimmt und erweitert.
Die Aussichten für RPM 6.0 sind die eines gestärkten Paketmanagers für das nächste Jahrzehnt: Bessere Kryptografie, Hochvolumenformat, leistungsfähigere Tools und aktuelle Dokumentation., mit einem klaren Kompatibilitätspfad für Administratoren, Paketierer und Ökosysteme, um neue Funktionen ohne Probleme zu übernehmen.
