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

[Phil Pennock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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-----

iQEcBAEBCAAGBQJTQePhAAoJEKBsj+IM0duF2OsIAKRPIPRA3OVMVJjR48+rIXM3
JzfywdJlYObA+BdZKpNxl2M4BQjLXvTc2qVQGcG0Pl0g0yjvFG9MWti8dhN9XzFv
QLpzIqUVYZHW+kcih6r0PBws9t1PKwloVz6o2HkpCeN45/I2z2LcHLsfb60OlDAE
FekCZH4x0hctHZBcnnuxtBi7gG5S4LRyXWZgGdocF0QVNloe/zwB9CIMZ4BVdICa
5cFJBL+Bd5fvh+vVGewRqCPE4bRPNCXZ7egleaf2NOKNjfNzlvgIbU5U4DdbOuMW
1L8pWvCwR+b26rdg4ti5Re5B7lldjeSwBFJp9gSt7cgtwPLIBo6yujbAPFJC0QY=
=qPa9
-----END PGP SIGNATURE-----