Public key encrypted verification of all distribution components should be used. GnuPG and/or SSL could be used; I suggest GnuPG. Implementation would be straightforward: * A trail of good verifications (see my previous bug posting saying SHA1s and RMD160s should be used in parallel with MD5s everywhere, since MD5s aren't that secure) should all lead eventually to public key encrypted verification. * Implementation options abound, but could include: + Parallel to SHA1, RMD160, and MD5 (as another method, with multiple entries) + As a new specification, an additional required step in a lot of processes * It is important that mutliple signatures be allowed for each verified item, for the following reasons: + Maintain signatures of tributaries (sources of data) without discarding their usefulness + Allow step by step signatures: each person who has access to the distribution chain can make an appropriate signing key with their own personally specified meanings, and some programatically meaningful meanings due to which keys are registered for which purposes. This way each step of the process has access to all previous keys (end administrator/user has access to Gentoo distributor's signature, Gentoo developer's signature, program distributor's signature, and program developer's signature). Default action could be to simply verify the most derived signature, e.g., usually the Gentoo distributor signing keys. + Multiple signings. Often, more than one person may know that a package is valid within the constraints of the meanings of one of their signing keys; they may all sign it as they see fit. + Keys need updating. Sometimes, keys become outdated or compromised, and new fresh signings must also be done. Old signings may persist when those keys are not immediately compromised to assist in transition from old key to new key verifications. Usually, the various entities involved would add signatures to items at least twice as often (more would be better) as it is appropriate they retire their keys. This allows time for new keys to be distributed, installed, approved, and configured before older keys become difficult to use. Distribution of a copy of actual keys (with most recent signatures, etc.) would be via the normal mechanisms where appropriate (key servers), but IN ADDITION and as the main source of them for Gentoo users, all those keys used and/or potentially used in Gentoo distribution would come with "emerge sync" as part of the portage tree, or at least as a package that is a prerequisite to portage (emerge). Since keyrings can get quite large (witness Debian's large keyring), an effort to keep only important keys there would be pertinent. Other methods could also be used: * A package of keys * Multiple keyrings, roughly composed of three subcategories: + A large keyring, containing all keys at time of creation, created and distributed approximately once per year or as appropriate according to size. + A medium keyring, containing all keys modified or new since large keyring, at time of creation, created and distributed approximately a handful of times per year when appropriate according to size constraints (such as four times a year, or whenever it makes sense) + Lots of little keyrings containing incremental updates since all of the last updates. The package programs would have a transitional mechanism which warns about packages without an ultimate trail to a signing key of appropriate value (such as specifically configured Gentoo distribution signing keys) (with configuration option to fail instead), and soon thereafter you would distribute a version of portage & emerge which would default to fail and abort without appropriate signing keys, with an override configuration option to just warn, but not to be used under any normal circumstance. This transitional approach is similar to my SHA1, RMD160, MD5 transition to using all three.
*** This bug has been marked as a duplicate of 5902 ***
