Re: [Sks-devel] SKS peering request [sks-server.randala.com]

[Martin Papik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


Dear Phil

First of all thank you for your exhaustive response, it's much
appreciated.

I'm running it on real HW, so the Ptree issues are not a problem,
although I am curious to know why and how such corruption happens on a
VM. Is it because of something specific to SKS or DBD? How was it
fixed in 1.1.4?

Second, with 1.1.3, are ECC signatures lost? Meaning if someone
queries my server running 1.1.3 for a key containing an ECC signature,
will only the one signature be missing or will there be problems
syncing any further signatures? I.e. will the whole key be lost, the
ECC signatures only, or any signature after the first ECC signature is
added? Another question that occurs to me is, how many ECC signatures
are actually in the wild? Are many users affected? If so, I wonder if
the logic that selects my server for inclusion in the pool is doing
the right thing. Mine isn't the only 1.1.3 server included. So I wonder.

I can't do much about OS packaging, it already took extra effort to
get 1.1.3 on the current stable version (not much, but extra), maybe
somebody here could undertake the effort needed to backport the latest
SKS for the stable branch of ubuntu. I've never done anything with
ocaml so I don't feel qualified to roll out a package. Not even for
myself to be honest. Or rather, I'm not in the best mental shape to be
responsible for such a thing.

So the question that sticks out is this, am I degrading the network by
being included in the pool with a 1.1.3 server? If so, what next?

Martin

On 04/07/2014 02:31 AM, Phil Pennock wrote:
> On 2014-04-06 at 13:49 +0300, Martin Papik wrote:
>> And my impression is that 1.1.3 is okay, a number of the servers 
>> visible on https://sks-keyservers.net/status/ are 1.1.3, and so
>> far the only difference I came across is that 1.1.3 doesn't
>> export server contact, which doesn't bother me overly. Is there a
>> better reason to upgrade?
> 
> If your machine is actually a VM rather than raw metal, then 1.1.4
> is almost essential to avoid database corruption issues ("Use
> unique timestamps for keydb to reduce occurrances of Ptree
> corruption").  Some caching and other fixes.  The main other reason
> is to support ECC PGP keys.  If you care about ECC, you'll want
> 1.1.4 or better.
> 
> I believe that Kristian is currently trying to coordinate getting
> some final changes in before a 1.1.5 release which will have enough
> cleanups and improvements in ECC and web security areas that it
> should be considered a "really really should upgrade" release.
> 
> The key aspect here is that OS packaging doesn't tend to draw
> clean distinctions between "stable dependencies which other
> software relies upon" and "service applications which are the
> reason this machine exists".  Often, for the latter group you want
> to try to stay very close to the upstream most-recent release.
> 
> As a classic example of the trade-offs: I'm involved with Exim.  If
> you have a system which just needs to send the occasional email and
> you want package installation to handle setting up new role email
> addresses and mailing-list integration for you, then you likely
> don't care about the most recent version and you want to stick to
> the configuration layouts provided by the OS packager.  On the
> other hand, if you're running a mail-server, then this is entirely
> the wrong approach, because the emphasis shifts to where the whole
> point of the server is this software and you'll want the latest
> improvements and fixes from upstream which reduce the problems when
> talking with others, you'll want support for current trends in
> email security and you'll want to have a configuration designed to
> be evaluated efficiently, for the million+ emails per day you
> handle per machine, instead of the 5.
> 
> So, figure out why you're running SKS and what your goals are.
> Decide if it's important to you for your server to be included in
> public pool definitions run by others, to provide a public service,
> or if you just care about local users and being useful enough to
> the community that others are prepared to bear the cost of
> providing you with feeds, so that you can connect into the mesh.
> (There is operational risk for the stability of your server, for
> each peer you have, as each peer is able to DoS your service with
> resource consumption attacks).
> 
> Once you know your answers to those issues, you'll know if you want
> to (1) stick with the minimal OS version which can talk to other
> servers; (2) run the most recent release, within T time of a new
> release; (3) run a local build from Mercurial tip.
> 
> Regards, -Phil
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTQhd3AAoJELsEaSRwbVYrKU0P/Au2nDXnBL3+ifEL9GWjz/EZ
JKbMTYNwg7OvVS323+BzIZlmjhzdNZFhMAyG12yjfMrazrjJkTvg0Is9F3gNnPLl
H1IUN2pyfpJEkfoGbGXZ9FcqQOFbu9RwWXLl8MqKv5oJaQMQpcC1CDEV6m30JD9E
hVO5G/zgAS3dcQG1L6Ax/jq8WmPUqXApFp65ohizAYhlkzj1wsihV0sEUggPg9Xk
2HeOCMIdwAMqoDFZLhDy4O0GEdYkcfkuPtCeuS/hh5lfkaYsslGeznv7gthfXYGa
dMcu1jcBDGO71PYgOXSeH4ryXjsKQE6W1xjwJ84E4Ifl+q5cZLf4ZnJL7zABtbqd
KQI5YeRB1PscWm+dx2igmX7GjQw+wWvO10uZ8uATMFCpOvJM+ALHQ8HwxgfqlLFv
ola8gf6NoJLNuFpaYwvGOrRlhM0q0/CDUUiXf3J0svFuB4WcpzomSQUMJZxFo+84
WcxxuV9Lxb9wqDt+jMyyltnCaNlRKcZwhQnqUHyvaypefL+gLJ98as3tad+y8VDz
SG6Ji4Ex2LmWlAc9NUMJ/8yIH0ZdWKIW07E09u7cgGZEnq2n6TiUxBwFxqmHnfrv
csdW9l8BrNaJSiiduMvLcK+bwR6ZIfungYlzWcN4DS6hXSVOapOwaEL6eN0p6k+1
/T4q0nDJq+4mie3HOHbQ
=7B6e
-----END PGP SIGNATURE-----