On Mon, Mar 10, 2025 at 12:44:44PM +0000, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855 > > This is a proposed Change for Fedora Linux. > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > > > == Summary == > Update RPM to the upcoming 6.0 major release. > > == Owner == > * Name: [[User:Pmatilai| Panu Matilainen]] > * Email: pmatilai@xxxxxxxxxx > == Benefit to Fedora == > > The major theme in 6.0 is increased security and related improvements: > * enforcing signature checking on by default snip > * support for automatic signing on package build (mainly for local use) Can someone elaborate on how this will work in practice ? Will RPM be autogenerate a local key per machine for the purpose of automatic signatures, that is already in the trusted keyring ? ie, so that 'rpmbuild ...spec && sudo rpm -ivh ...' will "just work" ? If so, how will this work if you add mock into the mix? Will the mock env use the local signing key from the "host" install, as opposed to a different local signing key in the mock chroot ? Or will we need to get the key used by mock and register it on the "host", in order to then install the just built package ? Also same question, but building in mock and then transferring the package over to a different machine for installation ? Can the local signing key from mock be easily transferred too ? > == Upgrade/compatibility impact == > > * Existing package build+install workflows may need to be adjusted due > to enforced signature checking being the default. > * 3rd party scripts and tools may need adjusting to the new key > addressing format and other signature related output changes. I presume the intent is that the (probably many) regressions that these changes will trigger, will *not* be considered justification to trigger the contingency plan, unless the impact unexpectedly severe ? IOW, we're fully expecting stuff to break and users are expected to do the work to fix compatibility asap. > == Contingency Plan == > > * Contingency mechanism: Revert back to RPM 4.20 > * Contingency deadline: Beta freeze > * Blocks release? No With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
