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

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

-----BEGIN PGP SIGNATURE-----

iQEBBAEWCgCpFiEEJaa7iN2bdkxrVUHCc4QJ9SDfkZAFAmoxJ5AbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQyNUE2QkI4OEREOUI3NjRDNkI1NTQx
QzI3Mzg0MDlGNTIwREY5MTkwDxxzYW1AZ2VudG9vLm9yZwAKCRBzhAn1IN+RkCbU
AQCmSNoaKaQF3pJkN4dIhFflL6DW2IgleC+M6HUS5T3eRAD+KJWcOJYuncAlX4O7
YI25ivfznDEscnff6aeFYhhK/gg=
=AdFo
-----END PGP SIGNATURE-----