diff options
| author | Eli Schwartz <eschwartz@gentoo.org> | 2024-11-27 15:09:21 -0500 |
|---|---|---|
| committer | Eli Schwartz <eschwartz@gentoo.org> | 2025-07-30 01:06:30 -0400 |
| commit | 4422a601583bdfadbe80a18115f5873c4a08f456 (patch) | |
| tree | a5bead93a8ddbb2cd27b66194140dc4cb92cab84 /dev-python/bitarray/bitarray-3.4.3.ebuild | |
| parent | c756f158bf0bb64b53b862eb728d40607f274981 (diff) | |
| download | gentoo-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
