On 11/27/24 4:12 PM, Michał Górny wrote: > On Wed, 2024-11-27 at 15:30 -0500, Eli Schwartz wrote: >> The current state of verify-sig support is a bit awkward. We rely on >> validating distfiles against a known trusted keyring, but creating the >> known trusted keyring is basically all manual verification. We somehow >> decide an ascii armored key is good enough without any portage >> assistance, then arrange to download it and trust it by Manifest hash. >> How do we know when updating a key is actually safe? >> >> This eclass handles the problem in a manner inspired in part by pacman. >> We require an eclass variable that lists all permitted PGP fingerprints, >> and the eclass is responsible checking that list against the keys we >> will install. It comes with a mechanism for computing SRC_URI for a >> couple of well known locations, or you can append your own in the >> ebuild. > > How about adding a src_test() that would check if the key needs bumping, > i.e. if an online update triggers any meaningful changes?
This is a really nice suggestion. I used Sam's tip about pgpdump, so that we print a diff after the online update, and fail if diff produces a diff. We use a cleaned and minimized version of the key, so it will only show/trigger on changes to the uid or self-sig packets, which isn't exactly the same as "meaningful changes". For example, running the tests on the gnutls keyring in the second patch, Daiki's key has been updated on Ubuntu with an additional expiry date change for a secondary uid, which may be meaningful in certain senses but we can validate it just fine using the primary uid. -- Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
