New keyserver at keys.openpgp.org - what's your take?

[Vincent Breitmoser]

Hi Konstantin,

> This is harder than it seems, so inability to use 3rd-party signatures is kind
> of a deal-breaker.

Sure is. There are ways to solve this problem, but at the moment they are all at
an early conceptual state at best.

For example, we could allow third-party signatures if they are cross-signed by
the signee (in an unhashed subpacket, for example).  Assuming a caff-style
workflow, this would be a fairly minor change to user workflows, and solve the
abuse issue because the owner of each key remains in charge of any signatures
published for it.

Wiktor also suggested before to accept key material from signed upload requests
(roughly "gpg --export keyid | gpg --sign-as keyid | curl). But I'm unsure of
how well this can really work in practice, given how hard it is to keep one's
local keyring in any kind of clean state.

Of course, closed user groups with different trust models and abuse
circumstances can solve this much more easily.

> I guess it would be easy enough to hack that into hagrid, but that would mean
> a hard fork and I'd avoid that at all costs.

Maintaining hagrid for the keys.openpgp.org use case takes up all the free time
I can spend on this project - which is why it is currently built to do exactly
that, no more no less.

I would be open to contributions that allowed the use of hagrid in other
scenarios such as this. More eyes on the code base sure wouldn't hurt. (I would
also probably be available for commissions, if you're into that :)

Note that, for better or worse, hagrid uses a filesystem-based database.  We
maintain all keys in the filesystem, and route most requests directly from
nginx, and the rest via x-accel-redirect.  This is not something everybody is
comfortable with, so beware ;)

 - V