Re: [Sks-devel] reverse proxies and the pool

[Phil Pennock]

On 2013-10-28 at 21:53 +0100, Gabor Kiss wrote:
> These efforts with HA pool reminds me bikeshedding.
> Wasting time with unremarkable things.

If there are three big problems, tackling them one by one while not
tackling the hardest _yet_ is not bikeshedding: it's improving the state
of affairs in manageable chunks, working slowly to gain consensus in a
community project.

Refusing to solve any of the problems because there's one really big
problem outstanding just leaves us in a worse state of affairs.  "The
perfect is the enemy of the good".  Folks working to solve this does not
take away energy from anyone working on solving the really big problem,
does not work at cross-purposes to it and generally is constructive.

> I just don't agree with this step because I truly think its benefits
> are illusory and it is devaluation of efforts of enthusiastic
> volunteers who make sacrifies for the public.

The benefits are a more reliably fast response from PGP keyservers by
the general public using the normal names (eg, "keys.gnupg.net" which is
a CNAME to "pool.sks-keyservers.net".)  This is not illusory: it reduces
frustration and helps PGP usage become more automatic, rather than
something to be disabled because it's causing problems and keeping the
email from getting out.

Anyone can volunteer to run a keyserver, and they can use whatever
configuration they like (as long as they can find peers).  Nobody is
proposing to stop peering with a non-proxied server.  You can use your
own keyserver, and you can encourage your friends to use your keyserver,
and you should do so to help preserve communicant privacy.

At question here is _one_ of the pool-maintainers, who runs the pools
which are "normal", working to change the pool which various people use
as a default, until such time as they know someone they trust to
preserve their privacy and so can choose to use a specific keyserver.

Anyone can run a pool if they disagree with Kristian's decisions;
Kristian's developed a good reputation and is generally trusted, so
folks in other projects go so far as to pick his pool as the default.

Kristian's PHP keyserver-pool software is open sourced:

  https://code.google.com/p/sks-keyservers-pool/

My own keyserver-pool software (Golang, some scripting for DNS) is open
source:

  https://github.com/philpennock/sks_spider

So that's two available code-bases, in a choice of languages, for anyone
to run a pool and compete in an open market for mindshare, by running
the best service which they think people will like.

I, for one, think that it's good that there is a population of
keyservers with different policies which different people can layer
pools over the top of, for the public good.  I think it's good that
there's no cabal forcing certain behaviour, just some guidance which
most people follow because it makes life easier.  Any forced
restrictions are purely technical (eg, stopping peering with software
which is so old that peering is just broken).

I think that the goal of making the default serving pool be as fast and
responsive as possible, without one slow client affecting every other
user, is a good one.  I think that switching the default to HA should
happen at some point, the only question is "when".

If we have enough reverse-proxy servers to provide decent latency to
every part of the world, then "any time after now" seems to be a
technically sound choice.  So, it seems to me that asking for input,
and if that has a rough consensus of "yes" then providing advance
notice, then making the change, is a very open and clear way to proceed
in how Kristian runs the volunteer service which _he_ runs.

To the extent that anyone other than Kristian has a vote as anything
more than a courtesy: I vote yes, it would be good for the main pool to
be HA-only, with a sub-pool for non-ha perhaps, and I think that a one
month lead-time would be very generous, giving people who want to stay
in the default pool but who haven't deployed a reverse proxy yet plenty
of time to do so.

-Phil

pgpN9JitZi7fi.pgp
Description: PGP signature