Re: [Sks-devel] SKS peering request [sks-server.randala.com]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 [Please do not top-post, it makes it difficult to follow the thread] On 04/07/2014 05:12 AM, Martin Papik wrote: 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? It relates to the timing information in the kernel clocksource not being accurate enough in some VM environments, so one of the workarounds is to use the tsc clocksource. 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? For signatures the ECC signature will be gone by default, or an error will be shown for a primary ECC key. The keys will synchronize and the full key can be gotten from a 1.1.3 server using clean=off option that disable the presentation filter. You'll find some details on number of ECC (primary) keys at [2] 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. ECC safe pool is the subset pool c.f. [0]. The 1.1.3 requirement is set mainly due to subkey safe searching. This will be bumped to 1.1.5 once released. 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? 1.1.3 should be reasonably safe (in the meaning I don't have any immediate plans to discard it form the pool), however do note that 1.1.4 was released in October 2012[1]. Martin ... 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. It would have its set of improvements, indeed. And you're correct in that I'm in favor of a new release soon, although I must state the disclaimer that we haven't decided on this in the team yet. References: [0] https://sks-keyservers.net/overview-of-pools.php#pool_subset [1] http://lists.nongnu.org/archive/html/sks-devel/2012-10/msg00010.html [2] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/ - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Qui audet vincit Who dares wins -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTQoA8AAoJEPw7F94F4Tag9wUP/1F++7EJu33NsjCaj+0KSo4/ DFiiD1PXifp35KyCBsdV4fLxAgeen7bdMq08qbaTp8CAiK4MK4O8CNOj359s54sN JI/hGIdMrcoTJp1RfCEee+9tdSiq0AIfm8HhZ2wdKcBF5gg1jumAV/wxX00V9rw3 KB+P+r83m6nS+BKMzAljKjX/WbFTr+7o13LKv1NSJO9Dfkpd2eLszCDAfVWixKw9 Tj0YmCuiKoQLIUDeWr8qQob4GSfLlLaBuuqBqn0SJNpQivo7pvF10mk5Z1bNkRhh qAWBxMKVLNhnB7ke1o2j5C5mkMg8LdgHUnWw4bIj3O/YRSXf+Q+A6QdhijOryh/J IKwri/xp2vdIE6NnPs7NJjg9O8zup0kRqE+f8glI6txmXFBzoNS5NjWPStewl13N 9SRixLiOTFkZoQ73QvBKu2IHcX0Z8yk9vGP0uR7JGbPKNC5vnBA7ZvImc+HJ2rqw ouwPvpmv8wFnps6CClDKlYS6VGi3gCQIvdnDpdm6B5lrshHDpRLlQmpKIWRoa0OQ 0tNnBmPb8ziQJDyGCmbOzh6bQ+54uGAjhi/Zvc25Vj0ORuDzIOKgscbkHGDb0lY7 IpOWEkCw0VCzUp4q95JFSR0cLF7qWJ3EvPR/9ODztuW3SM3OD2k0GeeF1IWVgQc2 VvfNFrGYUH699OT2uHrA =E96u -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS peering request [sks-server.randala.com]
-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- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Peering etiquette reminder
On Sun, Apr 06, 2014 at 11:37:50AM -0400, Jeremy T. Bouse wrote: Having just spent about an hour sifting through my recon.log and trying to track down the number of unauthorized gossip attempts I was seeing I've stopped. I've already contacted a few that I was able to identify and instead just figured I'd blanket the list as it seems to be a wider issue. I think there might be more to this than meets the eye. I just paid a visit to my own peering status page at: https://sks-keyservers.net/status/info/sks.disunitedstates.com I see a number of not ok's despite the fact that I have been in contact with these administrators and they agreed to peer with me. I have no idea what's going on here. Only one has ever contacted me to suggest that there was ever a problem--after I'd been aggressive about purging servers with whom peering didn't seem to be working. I think a larger conversation might be in order here. -- David Benfell benf...@parts-unknown.org See https://parts-unknown.org/node/2 if you don't understand the attachment. pgp45QsZKwBpI.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
