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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users