Re: gpg changesets (was Re: Bits from the DPL: DSA and buildds and DAM, oh my!)
On 2/24/07, Joey Hess <joeyh@debian.org> wrote:
Anthony Towns wrote:
> That's a technical issue, however -- one that seems like it should be
> emminently solvable. Ensuring that any such solution is written in a way
> that encourages auditability (of the code, of the input and of the output)
> is an important part though, and I don't know that anyone even has a good
> understanding of how that would be achieved. That probably means someone
> needs to try to implement it, and then we can see what doesn't work.
Perhaps something like this:
[ Very elaborate scheme snipped ]
I would have though that the keyring maintenance needs much simpler
tools. Is there really a need for editing individual keys? Looking at
the quote
] (c) right now changes to the keyring are fundamentally unauditable
] unless they're done by a single person on a trusted machine with
] trusted scripts. There are a bunch of ways to solve this, but
] the best suggestion I've heard so far is something that breaks
] down the 17Mb binary blob of 'debian-keyring.gpg' into single key
] auditable chunks that can then be managed in a sane way. The
] scripts to do these would have to be simple first and foremost so
] they could be audited.
it seems to me that a very simple solution would need
1. A trusted machine with a subversion (say) repository, to which only
the keyring-assistants have access.
2. A directory in this repository with one *.key file for each key in
the keyring. The *.key files should of course be in ACSII-armored
format.
3. A three-liner script that creates the keyring by importing all the
*.key file into an empty keyring, as AJT suggested.
So when a keyring-assistant processes a keyring request, like "My old
key 0xDEADBEEF is obsolete, here is my new one 0x12345678", the
assistant removes DEADBEEF.key and adds 12345678.key to the repository
with a commmit messages including the email with the request. When the
keyring maintainer has time, she verifies the commits, runs the script,
and uploads the new keyring.
The commits can be sent to a mailing list (or whatever) and other can
see that things are moving along, and verify the keys if they are so
inclined.
Or... is my understanding of what kinds of requests the keyring
maintainer gets wrong?
Cheers,
Jens Peter Secher.
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_.
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?
Reply to: