The CHECKSUM files are signed and I was too blind to see. Sorry for the noise.

Seems like this only affects the latest RC10, not all previous RCs and TCs.

FYI: RC10 was signed because it is going to be the final release.

We have tried signing RC's TC's we wil never sign they are throwaway like the nightly composes. It was requested that we do not sign RC's until one is declared gold.

The problem was that every RC was being signed with the same key which was intended to certify Gold releases (meaning that anyone verifying the signature wouldn't be verifying that it was a Gold release, only that it was one of the RCs, contrary to what the Verify page says). There wouldn't have been a problem with signing the TCs/RCs with a separate key meant for that purpose. Having said that, it may not be worth the trouble to sign TCs/RCs since very few people use them, and Alpha/Beta/Final Gold, which are used by many more people, do get signed. A relatively easy workaround would be to make sure the TC/RC announcement is signed by someone well-known, and to include all the image checksums in that announcement. Although I'm not sure that's worth the trouble either.

Every RPM is signed with the same key also. it does not Certify Gold release. It certifies that the content came from fedora.

The one key that's currently being used for each release is also being used to certify Gold release, in addition to signing the RPMs. That's why https://getfedora.org/verify refers to it - that page is intended to be used to check that an ISO is a Gold release (the ones announced to the general public), not just that it came from Fedora. If the TCs/RCs were also to be signed, it would have to be with a different key, or else the Verify page instructions wouldn't guarantee that people had the announced (Gold) images. The updates-testing RPMs used to be signed with a separate key, so there's precedent for it.

BTW, I think it made more sense to sign the updates-testing RPMs with a separate key, for the same reason. I realize it takes more resources to sign RPMs twice (once for testing and once for stable), but otherwise there's at least a theoretical risk that people who want only stable RPMs could get testing RPMs instead. Although this would require either changing the default repos, or the repos themselves being compromised.

The updates-testing RPMs used to be signed with a separate key, so there's precedent for it.

No they didn't, at least not back as far as F-10. Extras used to be signed with a different key, and since around Fedora 13 we've signed secondary arches with a different key.

In fact all releases use to be signed with the same key.

So I don't see a precedent here at all.

updates-testing used to be signed with a separate key. It was deemed to not be a good idea, so we changed to what we have today. I do not want to go back to something that was deemed a bad idea. We probably should engage with the Security team if we want to change anything. but I think what it boils down to is that different people have different perceptions, and taht will always be the case and we will not make everyone happy.

We no longer do TC composes, @adamwill do you see benefit to having all the RC composes signed? checksum wise? or should we continue as we have always done and only sign the CHECKSUMS once we sign off on a gold release?

as there has been no update I am going to assume status quo is fine and will close this. please reopen if that changes.