On 3/10/25 4:54 PM, Daniel P. Berrangé wrote:
On Mon, Mar 10, 2025 at 12:44:44PM +0000, Aoife Moloney via devel-announce wrote:
[...]
== 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" ?
It's not automatic. Rpm will come with a simple-to-use script/command to
set up automatic signing - create a special-purpose key, and output a
line that the user needs to execute to import. Think something in style
of (but don't take this literally):
$ rpm-setup-autosign
Generating key...
Run 'sudo rpmkeys --import /path/to/pubkey to import'
$ sudo rpmkeys --import /path/to/pubkey
After doing this once, rpmbuild && sudo rpm -U will "just work" on that
host, for that user. This is specifically the use-case the automatic
signing in rpmbuild is intended for.
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 ?
It's exactly for reasons like this that rpm will not even try to
automatically setup the signing - it has no way of knowing what the
right thing is.
Mock has it's own signing plugin, rpm wont interfere with it:
https://rpm-software-management.github.io/mock/Plugin-Sign
== 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.
To a degree, yes. The rpm team will help with the transition of course,
but each case is different.
Note that this behavior is a single line configurable item as mentioned
elsewhere in the change proposal, the only difference to 4.x is the
upstream default. Flipping that back to the 4.x default is a rather
simple temporary workaround for issues caused by this, and can be
supplied in eg mock per repo configuration when needed.
So if this turns out to be a bigger issue than expected we can certainly
flip the config to 4.x default temporarily in Fedora, it's just that I
would hate to ship rpm 6.x watered down to the terribly broken default
of 4.x. This change is 20 years overdue.
On that note, we could also turn this behavior off initially to stage
things a bit.
- Panu -
--
_______________________________________________
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
