Re: reduce/simplify the maintenance of sec-keys packages

Sam James <[email protected]> Tue, 16 Jun 2026 12:49:04 +0100
Newsgroups	gmane.linux.gentoo.devel
Organization	Gentoo
Message-ID	<[email protected]>
Agostino Sarubbo <[email protected]> writes:

> On martedì 16 giugno 2026 12:38:08 Ora legale dell’Europa centrale Sam James wrote:
>
>> Agostino Sarubbo <[email protected]> writes:
>
>> > Hello all,
>
>> > 
>
>> > right now we have 289 packages in the sec-keys directory.
>
>> 
>
>> I don't think that's a problem.
>
>> 
>
>> > I have not analyzed whether this is technically possible, but I am
>
>> > wondering whether it would make sense to create a dedicated Git
>
>> > repository on GitWeb, store all keys there, and have a single ebuild that
>
>> > installs all of them.
>
>> Could you explain what you see the issues with the current setup are?
>
>> 
>
>> The advantages of sec-keys.eclass are:
>
>> * It has fingerprints pinned in the ebuild, making it easy to audit
>
>> * It has a src_test to check for revoked keys or renewals that are
>
>> available
>
>> * Unexpected keys get flagged
>
>> 
>
>> > While this approach would install many keys for packages that are not
>
>> > present on the system, I think that is acceptable given that each key is
>
>> > only a few bytes in size.
>
>> > 
>
>> > With such a setup, whenever a new key is added we could simply create a
>
>> > new tag/snapshot of the repository.
>
>> The ebuild would be pretty complex then. We would need to verify the
>
>> filename matches the key fingerprint. How are we going to tie the key
>
>> fingerprint to the package? We want packages to be verified only by
>
>> relevant keys, not any key that is on the system.
>
>> 
>
>> > Alternatively, to simplify things even further, the sec-keys package could
>
>> > exist only as a live (9999) ebuild, eliminating almost all packaging work
>
>> > related to sec-keys.
>
>> 
>
>> That would mean users can't use verify-sig (ok, we say it's really a QA
>
>> check mostly for developers).
>
>> 
>
>> > Regarding this matter, we should add a way to rebuild the sec-keys package
>
>> > when you have installed it before the required key has been added. I
>
>> > don't know if is possible by looking at /var/db/pkg/*/*/BUILD_TIME
>
>> I think we should slow down and discuss why this (broader) change is
>
>> needed at all first.
>
>> 
>
>> > As I said before, I do not know whether this is technically possible. I am
>
>> > just trying to evaluate whether such an approach would be worthwhile and
>
>> > whether it would actually reduce the maintenance work associated with the
>
>> > sec-keys packages.
>
>> > 
>
>> > Agostino
>
>> 
>
>> sam
>
> Hi Sam,
>
> while I am not a native speaker, I reread my original message and it seems reasonably clear to me.
>
> I never said that having 289 packages in that directory is a problem, nor did I say that there are issues with the
> current setup. I simply suggested evaluating whether having a repository instead of hundreds of individual packages would
> simplify maintenance.

Yes, that's OK, what i mean is: if you make a proposal, it is useful to
state what problems you see, and how it addresses them.

>
> Even without having our own repository, this is essentially what happens with linux-firmware, where we do not maintain a
> separate ebuild for every individual firmware file.
>

linux-firmware is different because it is maintained as a collection
upstream. There's also not really any separate processing we could do on
individual files.

Here, we have packages which consume a subset of files, and that subset
is disjoint (not in common with other packages in general, just a few
cases).

But we also have individual processing and testing/verification we can
do on those, which is not relevant for linux-firmware.

> My goal was not to push for a change, but rather to understand together whether the proposal would bring any real
> improvements. If the answer is no, I'm happy as-is.

But can you help me understand what problem you're trying to address?

sam
signature.asc (application/pgp-signature, 418 B)