During signing builds, the files in it will be signed with IMA signatures.. These signatures will be made with a key that’s kept by the Fedora Infrastructure team, and installed on the sign vaults.
What is the impact on RPM database size?
They're stored in xattr so it shouldn't have any noticeable impact, although Patrick can confirm the details of that.
If the signatures end up in RPM headers, they will land in the RPM database, too.
“rpm -qla | wc -l” shows around 28,589 files for me, in the Fedora 33 container image. / seems to need 183 MiB right now. If the signatures land in the RPM database and the file system, I expect at least 96 bytes per file signature (digests in the header are traditionally hex-encoded, I think). That translates to 2.6 MiB, or ~1.4% size increase.
But quite likely there is some per-block overhead, so the numbers should be worse.
Will GPLv3 packages be excluded, or will the signing keys be provided upon request?
The public key?
The private key. IMA is typically used for some form of remote
There's no requirement of the GPLv3 to redistribute the private key for this usecase, we're not denying access or restricting use of the OS: https://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys
attestation, I think. I'm not sure if it is possible to distribute hardware with IMA enforcement. And as long as enforcement can be turned of trivially (as required by the GPLv3, as far as I can tell), IMA seems to be pretty useless.
Like most things end users if they're not onselling/distributing to third parties can use technologies such as IMA to reduce the attack surface or increase their ability to audit their own systems as they like.
Like most security tooling it's about layers of security and functionality.