Open keszybz opened 4 months ago
We already do that. For long time. https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/fedora-rawhide.tpl#L45
IIUC, that is doing F(N-1), but we actually need F(N+1). The proof is in the pudding, as they say: mock clearly fails, so I think the existing code must not be enough.
Can we implement this as @keszybz proposes, and to not fail - always provide, in distribution-gpg-keys, the Fedora Rawhide +1
Key? I assume that there's a race and we don't always have the official Rawhide+1 key :-) but for the limited period when we do not have it, we can provide/fake it temporarily as a 1:1 copy of the Rawhide Key -> and replace, it once available.
See #1342. But I think that next time we should also pay more attention to providing updated mock-core-configs (with the new branched configs) earlier than this time (the guilty release was far from optimal and too late). If the updated configs are distributed in time, the problems with Rawhide shouldn't appear.
Just trying my best to communicate the issue to the Fedora Releng team: https://pagure.io/releng/issue/12001
Every time we branch, there is a short period when local configuration thinks Rawhide==FN, but actually Rawhide==F(N+1), and gpg key verification fails. After branching, the packages in the F(N+1) compose are resigned using the F(N+1) key, so they do not pass verification with FN key.
It turns out that it's fairly easy to avoid this problem by importing the additional key. I did such a change for mkosi and it solves the issue [1].
[1] https://github.com/systemd/mkosi/commit/f221562c945a48db9384f8521f67b9b02cd71ac1