Red Hat has released the second beta of the RPM package manager 6.0, which will be used in the fall release of the Fedora Linux 43 distribution. The project is utilized in distributions such as RHEL, Fedora, SUSE, openSUSE, ALT Linux, Rosa Linux, OpenMandriva, Mageia, PCLinuxOS, and Tizen. The RPM code is distributed under the GPLv2 and LGPLv2 licenses. Version 5 of RPM was skipped to avoid overlaps with the RPM5 project, which is unrelated to Red Hat's RPM and was developed by independent developers.
Improvements in the second beta version include support for OpenPGP v6 digital signatures. The update also offers fixes related to package verification through digital signatures. General changes in the RPM 6.0 branch include:
- 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.
- 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
