On Wed, 13 Mar 2019 at 15:42, sebb <[email protected]> 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. > > > 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. > > KEYS will grow and grow. > That is not very friendly to downloaders who want to use the KEYS file. > > 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.
Also, not all projects have a KEYS file in the canonical location ( /repos/dist/$PMC/release/KEYS) And some projects maintain the KEYS file elsewhere and copy it to the canonical location. However, if there really is an issue with the work needed to update the KEYS files, then maybe there could be a tool to make it easier for a release signer to add their key to whatever KEYS file is maintained by their project. > Sebb.
