The release of the RPM package manager 6.0 has been announced, which will be utilized in the release of Fedora Linux 43. The project is being developed by Red Hat and is used in distributions such as RHEL, Fedora, SUSE, openSUSE, ALT Linux, Rosa Linux, OpenMandriva, Mageia, PCLinuxOS, and Tizen. The project's code is distributed under the GPLv2 and LGPLv2 licenses. Version 5 of RPM has been skipped to avoid overlaps with the RPM5 project, which is not related to Red Hat's RPM and was developed by independent developers.
Key changes in RPM 6.0:
- Support for the new RPM 6 package format, allowing the creation of packages larger than 4 GB. The RPM 6 format employs 64-bit fields for sizes, modernized structures related to cryptography, and added MIME information about files.
- Support for the RPM 3 format has been discontinued. Full support for the RPM 4 format, which uses cpio, will be maintained; distributions can choose to remain on RPM 4 format at their discretion.
- By default, package authenticity checks using digital signatures are enabled.
- The rpmbuild utility has been updated to support automatic generation of local signatures during the build, and the rpm utility has added the option ‘—nosignature’ for forcibly installing a package without signature verification.
- It is now possible to use the Sequoia-sq toolkit, written in Rust, instead of GnuPG.
- Development is now permitted in C++ (C++20), not just in C.
- Support for using multiple OpenPGP signatures for each package has been implemented.
- Support for MD5, SHA1, and DSA hashes has been discontinued.
- The rpmkeys utility has been enhanced for key management; for example, to update OpenPGP keys, use the command ‘rpmkeys —import’.
- Only complete identifiers and fingerprint hashes of OpenPGP keys are now utilized.
- Support for OpenPGP v6 digital signatures has been added, along with the ability to use cryptographic algorithms resistant to quantum computer attacks.
- It is now possible to update already imported keys.
- In the Python language bindings, support for isolating the state of Python modules to run them in multiple sub-interpreters has been implemented.
Source: opennet.ru
