>> > 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.