Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

[Martin Dobrev]

Hi

On 06/02/2019 19:28, Robert J. Hansen wrote:

If only it were open-source software and individuals with the extra time
and talent to work on those design flaws were able to do so. Wouldn't
that be a great world to live in?

Wouldn't it be great if people were to think before snarking?

There are a handful of people with the background and skills to write a
next-generation keyserver.  I looked into it a dozen years ago and wrote
up a whitepaper on it.  I know Phil Pennock has put a lot of thought
into it.  Andrew, likewise.  There are easily five or six people on this
list who have the time and ability.

I'm glad to see from server operator perspective that there is a will to invest time in developing the server.

What we don't have is *consensus* -- not only among ourselves, but in
the larger community.

Let's say I decide to implement my whitepaper from 2007.  It would take,
oh, call it 200 hours of work to implement.  So I write it, put it out
there, and nothing happens because there's no consensus my idea is the
direction we should go.

The problem here is not a lack of manpower or skill.

It's a lack of community consensus on what a redesign should look like.

Is there a place where white-papers and draft proposals can be found? I remember seeing proposals to change the backend database with something that supports transactions, the likes of postgresql or mysql. Without it multi-threaded server is not possible. If I had the knowledge of OCAML I'd start like immediately a fork and implement it in order to save disk space and more important cut on redundant Iops. Nearly 21K keys have been added for the past month. Looking at the graph again I don't see a single plunge just steady growth. As it stands I'm running two physical servers with four Docker containers each that take approximately 95GB. Even with a single-thread server implementation I can still run multiple containers with a shared database, isn't it?

I agree redesign is inevitable if we want to address legislation changes like GDPR for example. A lot of servers in Europe ceased operation because of it. Today I read the news that criminals are using block-chain network to upload child abuse photos. According to UK law hosting such content can lead to large convictions. I don't want to be forced to stop my clusters if criminals exploit the photo field in the protocol. In my opinion there must be a way to remove content that's not legal from the network.

The way I see this happening is by introducing blacklists that a) prevent a key from being fetched during recon and b) delete the local copy of it. Is this a censorship?! For what I know some of us are already using blacklists to mitigate the poison key issues, the very least I am.

Building upon the previous suggestion I'm actually envisioning different types of blacklists in terms of legislation framework they comply with. Subdomains like <blacklist>.pool.sks-keyservers.net can be introduced as well. Then individual keyserver operators can configure what blacklists to use. A public register will keep the audit trail justifying every blacklist entry and used as a seed for the servers in the network. And before you ask who's going to be responsible for keeping that register up-to-date and accurate I have an answer for you - the very same law enforcement agencies that in the very first place demanded that we remove content from the network.

That being said I believe these changes will make the network a safer place not just for the operators but the users as well. That's something, I think, we as community can easily achieve consensus upon.

Sadly I don't have a  solution for the recent poison key issues that opened this thread in first place. We eventually need a brand new RFC that will define the next-gen server architecture.

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc
Description: OpenPGP digital signature