On 8/20/19 6:40 PM, Kevin Fenzi wrote:
On 8/20/19 7:37 AM, Petr Mensik wrote:
> I could not find a safe way to upgrade also this time. I found update
> F32 , but not corresponding F31 just adding new key. I am missing
> update similar to , just for F31 that once was Rawhide. It should be
> version 31-0.5
> I found and reopened one old bug . I do not think this is just second
Yes, it is that version, but there is not any compose that it exists in
> On 8/19/19 11:32 PM, Kevin Fenzi wrote:
>> So, a few things to note:
>> * fedora-repos was updated for rawhide, however, unfortunately, It had
>> two extra spaces on the first line... " " which made gpg consider it
>> invalid. This is likely the cause of any breakage with rawhide (mock,
>> containers, copr, etc). This has been fixed in the newest fedora-repos
>> package for f32/rawhide.
>> * There is no f31 repo because we have not yet had a fedora 31 branched
>> compose finish. So, mirrormanager is pointing people to rawhide. This is
>> likely the cause of all problems related to f31.
> I think this is a major point. I could not find update with
> fedora-repos-31-0.5 signed. Instead, there is 32-0.1 served both by f31
> updates and rawhide repo. I think there must be first updated GPG keys
> N, which increases just minor version, not a major one. Major version
> should be increased only after branching. Unless I am mistaken, rawhide
> served me 32-0.1 signed by key contained inside. Okay, I had rawhide
> repo enabled. But even
> $ dnf --repo=updates --releasever=31 upgrade fedora-gpg-keys
> did not offer different version. What was worse, both were signed by the
> same F32 key.
yes, because both f31 and f32 are currently pointing to f32 (rawhide).
If we had a f31 compose you would not have hit this. You would update to
the new f31 version and from there you could upgrade to f32 or stay on f31.
I think f32 key should NOT be used until this is fully separated and
compose for older versions exist. Unless that key was leaked somehow,
there is no hurry, right? That hurry makes pain to many people without
justification for it,
There would always be mass rebuild in later stage of F32, no need to
switch key immediately. I think new key should not be enabled for
signing in new Rawhide until all supported versions have that key in
stable updates repo. That is not yet true now.
I am thinking, is there written guidance how to switch signing key on a
branch? Are we prepared for emergency in case that key was leaked?
Red Hat, http://www.redhat.com/
email: pemensik(a)redhat.com PGP: 65C6C973