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

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