On Wed, Mar 13, 2019 at 03:42:13PM +0000, sebb wrote: > On Wed, 13 Mar 2019 at 15:15, Daniel Shahaf <[email protected]> wrote: > > > > [ removing dev@svn, adding dev@whimsy — sorry if that's not the right list. > > ] > > > > Sebb, > > > > KEYS formats have multiple problems. They are a custom format that > > needs to be updated by hand, and if someone is a committer on N projects > > then he needs to do O(N) work to update their keys. That's a very poor > > design > > from a human factors point of view. > > They only need to add their key on projects where they have signed a release. > > That is a much smaller number. >
It's still O(N⋅M) work that you are inflicting on everyone, year on year, whereas the solution I proposed is O(1) work, one time. Also, you require everyone to keep state: "Oh, new serf release. Let me sign it. Hmm, have I signed a serf release since I created my new annual signing subkey?…" > > p.a.o/keys/ was invented to solve these problems. If it has downsides, > > fine, but don't throw the baby out with the bathwater. > > > > It would be better to change the p.a.o/keys/ cron job (1) to work, not > > off of LDAP but off of an append-only dataset mapping PMCs to committers > > and committers to keys; and (2) instead of publishing the results on > > minotaur, to auto-commit them to /repos/dist/$PMC/release/KEYS. > > I think that will cause problems. > > KEYS are used for archives validation as well. > Entries should not be deleted if they have ever been used to sign a release. You haven't actually explained what problem you see here in context of my proposal. Did you see the words "append-only" in my proposal? Did you observe how my prototype code creates an append-only set of unix names? The same would be done with the lists of committers per PMC and keyids per committer. Thus the files would be append-only (not in the line-based, 'echo >>' sense but in the set-of-OpenPGP-packets sense). Also, it is not a law of nature that each project shall have exactly one KEYS file for all their releases, current and historical. It's simply a system that somebody wrote up fifteen years ago, and it has its bugs. Just to illustrate how arbitrary the current system is, why shouldn't there be a convention that foo.tar.gz be accompanied by foo.tar.gz.keys? That file would be created as a symlink to some file that contains all the right keys. Each PMC could have, say, one KEYS file per year, and each release's .keys symlink would target the appropriate KEYS file. > KEYS will grow and grow. No, they won't. /keys/group/foo.asc and /dist/release/foo/KEYS contain the same data. > Also I am wary about allowing a bot to update the KEYS file. > The provenance of the data is not nearly so easy to establish. The PGP security model does not require public keys to be transported over an authenticated channel. Daniel
