Background
Package archive signing will enable verification of package archive index files
and establish a chain of trust (through SHA256sum
fields) to verify individual
packages. It will allow ProteanOS's package management tools to more securely
retrieve packages from the archive.
Implementation
TODO: ProteanOS is implementing Ed25519 signatures, likely without OpenPGP PKI. The pro-archman and prokit sections below will need some rethinking.
TODO: Consider ucert.
ProteanOS Archive Manager
pro-archman will gain a new option: an archive signing key.
If a key is provided, pro-archman will run gpg
to sign, with the specified
key, Packages
feed index files when generated.
A gpg
executable will be an optional dependency, found by the configure
script at build time.
ProteanOS Development Kit
prokit will verify package feed index files with gpg
if
configured in the profile, and the proteanos
profile will enable such
verification.
A gpg
executable will be an optional dependency, found by the configure
script at build time.
A keyring (or ASCII-armored keys that are added to a keyring at either build time or run time) associated with the profile should probably be included with prokit. Otherwise, a user would need to manually import the archive signing key(s) into their keyring.
If keys are distributed with prokit, revocations and key transitions need to be handled somehow.
New keys can be distributed with new versions of prokit, though this would require users to upgrade prokit to get new keys. Revocations, being more of a security risk that can go unnoticed by users, would need to be more actively and immediately received by users. prokit could perhaps check a key server (over HKPS) each time before using a key.
And if prokit needs to check key servers anyway, it could also use them to find new archive signing keys, as long as at least one "seed" key is distributed with prokit. prokit should find and use only archive signing keys (by a user ID specified in the profile) that are signed by a non-revoked previous key (or a signed chain of keys with the user ID).
A user already has to import a key into their own keyring to verify their prokit download. Maybe it's better to just instruct users to also download the archive signing key(s) into their keyrings. This takes advantage of existing PKI, and leaves users to make sure their keyring is kept updated with signatures, revocations, changed expiration dates, and transitions. It also avoids having released prokit versions "expire" due to included keys expiring.
Suggestions welcome.
Opkg
ProteanOS ?now uses opkg-lede with usign, a lightweight implementation of the Ed25519 public-key signature system.
Archive Keyring
The package archive keyring will need to be maintained in a ProteanOS package. Key transitions, expiration changes, and revocations will be performed by revisions to this package. It should possibly be upgraded automatically to ensure that installed systems always have up-to-date keys.