On Tue, 16 Oct 2012 22:54:04 +0000 "Robin H. Johnson" <[email protected]> wrote:
> Previously, the PORTAGE_GPG_KEY variable has allowed ANY argument, and > passed it to GPG, letting GPG use that. This was intended to explicitly > be a unique identifier for a key (or subkey). > > However, it seems that there are signed commits with other values in the > variable, and instead of something nice like: > (Portage version: 2.2.0_alpha138/cvs/Linux x86_64, signed Manifest commit > with key 0x586A3B1F) > We have commits with: > (Portage version: 2.2.0_alpha138/cvs/Linux x86_64, signed Manifest commit > with key emailaddress) > > This makes validation harder, as we need to extract the identity of the > key from the Manifest before we can proceed. Additionally, if a > developer has multiple keys, possibly over time, we cannot use this > string to identify what key was used easily. > > As such, we've decided to make the PORTAGE_GPG_KEY strictly enforce what > was originally intended. > > - You must specify a key or subkey exactly. > - The leading "0x" is optional. > - If you want to use a subkey, per the PGP specifications, you must > suffix your keyid with "!". > - Your keyid is exactly: 8, 16, 24, 32 xor 40 hexdigits long. Isn't that fixing the issue from the wrong end? I agree that the keyids in commit messages should follow some kind of spec. But I rather think that portage should be modified to convert any supported argument to follow that spec rather than the spec being forced into the configuration file. Also, will that matter anymore after the git conversion? -- Best regards, Michał Górny
signature.asc
Description: PGP signature
