summaryrefslogtreecommitdiff
path: root/dev-python/bitarray/bitarray-3.4.3.ebuild
diff options
context:
space:
mode:
authorEli Schwartz <eschwartz@gentoo.org>2024-11-27 15:09:21 -0500
committerEli Schwartz <eschwartz@gentoo.org>2025-07-30 01:06:30 -0400
commit4422a601583bdfadbe80a18115f5873c4a08f456 (patch)
treea5bead93a8ddbb2cd27b66194140dc4cb92cab84 /dev-python/bitarray/bitarray-3.4.3.ebuild
parentc756f158bf0bb64b53b862eb728d40607f274981 (diff)
downloadgentoo-4422a601583bdfadbe80a18115f5873c4a08f456.tar.gz
gentoo-4422a601583bdfadbe80a18115f5873c4a08f456.tar.bz2
gentoo-4422a601583bdfadbe80a18115f5873c4a08f456.zip
sec-keys.eclass: new eclass
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. Key rotations, both expected and malicious, are easily detected by checking the git log for changes to declared fingerprints in a bump. The former can be rationalized in the commit message. So can the latter, but in most cases those will be rejected during peer review. Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Diffstat (limited to 'dev-python/bitarray/bitarray-3.4.3.ebuild')
0 files changed, 0 insertions, 0 deletions