Re: [Sks-devel] SKS peering request [sks-server.randala.com]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/09/2014 02:36 AM, Martin Papik wrote: Dear Kristian Thank you for your response. 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] So all the keys will be in the database on a 1.1.3 server, but searching for ECC keys will fail with an error, and ECC signatures will be omitted due to the filter which can be disabled with clean=off. Did I understand you correctly? In which case, a 1.1.4 ... yup server that is only peering with a single 1.1.3 server which peers with the networ will get all the keys and return correct results. Is that true? Will a dump on a 1.1.3 contain the ECC key material? ... yup 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. Which requirement is this? For the ECC-safe pool? Because otherwise this seems to contradict the next paragraph. the subset pool was linked as reference [0] 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]. 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. Do you have a time frame in mind? No specific timeframe, I have an outstanding pull request on its way into the main tree, after that I'm ready to go after some release preparations, but it depends on whether the rest of the team has anything outstanding. Are the planned improvements documented somewhere? Are they in the repository in the TODO file? they are in the CHANGELOG [a]. The todo file isn't really used, we use the issue tracker instead. Is the repository always the latest version? I don't understand this question. Is the repository always safe to run? I mean, can the head always be safely deployed to be part of the public network? No, it is a development branch. However, it is mostly iterative and as such save, but always is a very strong requirement. PS, sorry if my questions are tedious, but I'm new to sks so there's a lot that's not clear to me and I would like to make sure I don't misunderstand something. I hope it's okay. Sure.. References: [a] https://bitbucket.org/skskeyserver/sks-keyserver/src/tip/CHANGELOG?at=default - -- - 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 - Docendo discimus We learn by teaching -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTRPajAAoJEPw7F94F4TagyxUP/1N7UcUr6KIBkF/rxBF9ebN0 OmjE4HpA5J/s7ymrm74KuNYZUnVR7WLzCfe94mAEUDtWKfD/gxRBdD59ip4xLe/G HyL9xhJ/fDW9uC6OAMPB0rxm1vpptipVKf7FtHaJsiAVIb9PLHjZHATNNyTmQpDx aJ86GXsJaWaLQbF0o8QC92xjHF1aUVPspmS3jTrXUTqLMPxXmFtuLttuL4EzA+bb VycOUm0RB7F1e9E5ahQ75wTgS0HbmmkDD0+WW8P9LROwfUeF/XCJDXTCCYV0nsKc Litg9cTKuKLmAD1vwO526MXRxU2cmycki26PRAwIW+PT18xE+2LXBPrW/5zRrK4F lQOJTxd0GGN8tIeA41OIyqgQM2QGNiLozdAtrcJx6Xr6+0p1tcjbEml4xfCX2DHr ZqFjxTLuNFCK+muhwlc1MswcY7cR3+xOwuVkvOP4gHJRYM3teqGQpBJRGUVgnmRr yAANAZhY70hAoVgD1WAv2AK+Yj2IGRxj2ctzfIULp+E3Y/DzYqeYVaPs+iqNsIPm UpOARkoMvXBt5KWIHW23z0oOv/nMZ2nOAwMx/RabpzEy6FOKpHk/UgsfZSbP9TaC n1ZGWg5svLBYgFw7+Cb4HMYWM7oYvxwUGY3+OsSbODpGKLk5XouSfBy3sSK+Kbv1 6VRTVWS7QCldvOy1Lg76 =Qq8Y -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: SHA512 Dear Kristian Thank you for your response. 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] So all the keys will be in the database on a 1.1.3 server, but searching for ECC keys will fail with an error, and ECC signatures will be omitted due to the filter which can be disabled with clean=off. Did I understand you correctly? In which case, a 1.1.4 server that is only peering with a single 1.1.3 server which peers with the networ will get all the keys and return correct results. Is that true? Will a dump on a 1.1.3 contain the ECC key material? 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. Which requirement is this? For the ECC-safe pool? Because otherwise this seems to contradict the next paragraph. 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]. 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. Do you have a time frame in mind? Are the planned improvements documented somewhere? Are they in the repository in the TODO file? Is the repository always the latest version? Is the repository always safe to run? I mean, can the head always be safely deployed to be part of the public network? PS, sorry if my questions are tedious, but I'm new to sks so there's a lot that's not clear to me and I would like to make sure I don't misunderstand something. I hope it's okay. Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTRJX7AAoJELsEaSRwbVYrqvkP/Rov7oiy2Jssq0TxD6KzHUeJ R7GlqFJpY9U0eSfPiekKwNLMLYGhfOjLaaMUR/tCY0Bj61Hzlefb8YcAE+A+xM4W VYyMRN6kG1lFWM0K+e4+USlNu3tL2yqgxveYKhdLDn3n2Tih49QItNpuy/cqujPh Cl+I109Nok+kZJsDsC1TcPzNA7ElM7wIjstIK7Vz830jXVIdMpQIElo33vYamgp4 PWArv5n8nTSWdPtLQS3qftPzT76TdjB89lasfJc/3Xudl+/TbOGUcPdRoTLUU+Ya 1HyumOm4br6ecuqa2cjHGYvZ2zti1qcwnjoPuU3/Eby6ei6pSF2BzeADcizbNDG2 WD3bcFKBfcGff4YLbktjUYn1MrTyf8m3vs7ZoQFlAYngz7yqLgx9wOELjfET1Ari qaAUO89y2zYBwfyJpuTyreAGtu47y2/4fdDm8R50JHkwezV/pzPUgPiZIPhhKVR5 meT4Y07LHerBR5EoRg55L/Y/JFBZ4vSGcP6dZFBoPmNLhsZvp/TfGLe5VAobZfxj O1Yo9t03isA0TMrdGWLpmrZRIMPnzfxsSbG7Dyk0bEU4cS6adD3lIjfiMwiJvdfC 7rBqoRVLwqO3lcXDb02csn+nsZylNNe0BALIK1VQjSyniZcyvOL4GUTfD0vSGu9T wUlQM+mU2MCG0K45wCcs =UC66 -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: 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] SKS peering request [sks-server.randala.com]
Hi, if you'd be using the latest Ubuntu, you would probably also have access to the newest SKS version in the repositories. ;-) Ubuntu 14.04 LTS will come out soon; upgrading to that should give you 1.1.4. If your server is running on amd64, you can use this .deb for now, if you want to: http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb Best regards, Tobias Frei Am 05.04.2014 16:17, schrieb Martin Papik: Thank you, I've upgraded to 1.1.3, although why Ubuntu didn't install that one without an explicit parameter boggles me a bit. Oh well. Is that sufficient, or will I have to install the very latest from source? The web server is enabled, there's just no main page in the directory yet. I see Error fetching key from hash : Not_found messages in the log though, is this normal? The hashes update, so I'm not overly worried, just want to know if this is normal. Anyway, thanks again for taking the time to assist me. Martin On 04/05/2014 04:38 PM, BluKeyserver wrote: Hi Martin, Quoting from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 'Versions prior to 1.1.2 have a severe interoperability bug (POST requests for exchanging keys are HTTP/0.9, does not work with modern setups having reverse HTTP proxies in front as a best practice.' Perhaps it's a time to ditch the 1.1.1 and try to compile 1.1.4 instead ? Also, I have noticed, that you did not enable the built-in www server: 'Page not found: /var/lib/sks/www/index.html' Regards, H.Storm [TheBluProject] On 05/04/2014 07:52, Martin Papik wrote: Thank you very much Jerzy, however I'm facing some problems. I wonder if you have any insight. I'm new to sks, but it seems to me that there might be an apache proxy intercepting the connections and interfering somehow. I don't see my server in http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but the sks servers are talking to each other on 11370 so I'm assuming there's some kind of asymmetric setup. Any help would be appreciated. Martin In the log I see (after incrementing http_fetch_size to 1000 to reduce the number of entries). 2014-04-05 08:43:40 address for keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET [176.241.243.15]:11370, ADDR_INET [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 54ABD9C187E4555DB2377ABFCD29D8B8 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 7E819BE55160DDBD06E480F74F1D6017 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with A7E5518397DB6A961E9FB8B59C1391D6 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with D348A85B40F5C08C3CA2E9AB09EF2CB0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 64 missing keys from ADDR_INET [176.241.243.15]:11371, starting with FD40B34ECD8971CFCECF9E79D48772F0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) The tcpdump output contains (looks like HTTP 0.9, no host header in the request, no HTTP headers in the response). Request to 176.241.243.15:11371 POST /pks/hashquery content-length: 24 Response from 176.241.243.15:11371 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title502 Proxy Error/title /headbody h1Proxy Error/h1 pThe proxy server received an invalid response from an upstream server.br / The proxy server could not handle the request ema href=/pks/hashqueryPOSTnbsp;/pks/hashquery/a/em.p Reason: strongError reading from remote server/strong/p/p hr addressApache Server at keyserver.kolosowscy.pl Port 80/address /body/html On 04/05/2014 04:21 AM, Jerzy Ko?osowski wrote: Hi, I added your server. My line to add: keyserver.kolosowscy.pl 11370 # Jerzy Kolosowski je...@kolosowscy.pl Rgds, Jerzy
Re: [Sks-devel] SKS peering request [sks-server.randala.com]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am using the latest stable LTS, unfortunately, ubuntu LTS matures slowly and I've been bitten with premature dist-upgrades. I'll choose waiting over being a test-case. At least on anything that's exposed to the internet. # wget http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb # dpkg -i sks_1.1.4-2.1ubuntu1_amd64.deb (Reading database ... 97126 files and directories currently installed.) Preparing to replace sks 1.1.1+dpkgv3-7ubuntu0.3 (using sks_1.1.4-2.1ubuntu1_amd64.deb) ... Stopping sks daemons: sksrecon.. sksdb.. done. Unpacking replacement sks ... dpkg: dependency problems prevent configuration of sks: sks depends on libdb5.3; however: Package libdb5.3 is not installed. dpkg: error processing sks (--install): dependency problems - leaving unconfigured Processing triggers for ureadahead ... Processing triggers for man-db ... Errors were encountered while processing: sks # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.4 LTS Doesn't seem to work, I tried adding deb http://us.archive.ubuntu.com/ubuntu/ trusty main universe to /etc/apt/sources.list, but just installing sks would replace libc, which basically means I might as well dist-upgrade, which I won't do just yet. PS in my personal experience with the last ubuntu LTS increment, it will be stable enough sometimes next year. Until then, I'm afraid I only have three options, compile from sources (headache, error prone, extra maintenance), wait for someone to backport 1.1.4 on 10.4 or 12.4, or just leave it as 1.1.3. 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? Martin On 04/06/2014 12:07 PM, Tobias Frei wrote: Hi, if you'd be using the latest Ubuntu, you would probably also have access to the newest SKS version in the repositories. ;-) Ubuntu 14.04 LTS will come out soon; upgrading to that should give you 1.1.4. If your server is running on amd64, you can use this .deb for now, if you want to: http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb Best regards, Tobias Frei Am 05.04.2014 16:17, schrieb Martin Papik: Thank you, I've upgraded to 1.1.3, although why Ubuntu didn't install that one without an explicit parameter boggles me a bit. Oh well. Is that sufficient, or will I have to install the very latest from source? The web server is enabled, there's just no main page in the directory yet. I see Error fetching key from hash : Not_found messages in the log though, is this normal? The hashes update, so I'm not overly worried, just want to know if this is normal. Anyway, thanks again for taking the time to assist me. Martin On 04/05/2014 04:38 PM, BluKeyserver wrote: Hi Martin, Quoting from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 'Versions prior to 1.1.2 have a severe interoperability bug (POST requests for exchanging keys are HTTP/0.9, does not work with modern setups having reverse HTTP proxies in front as a best practice.' Perhaps it's a time to ditch the 1.1.1 and try to compile 1.1.4 instead ? Also, I have noticed, that you did not enable the built-in www server: 'Page not found: /var/lib/sks/www/index.html' Regards, H.Storm [TheBluProject] On 05/04/2014 07:52, Martin Papik wrote: Thank you very much Jerzy, however I'm facing some problems. I wonder if you have any insight. I'm new to sks, but it seems to me that there might be an apache proxy intercepting the connections and interfering somehow. I don't see my server in http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but the sks servers are talking to each other on 11370 so I'm assuming there's some kind of asymmetric setup. Any help would be appreciated. Martin In the log I see (after incrementing http_fetch_size to 1000 to reduce the number of entries). 2014-04-05 08:43:40 address for keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET [176.241.243.15]:11370, ADDR_INET [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371,
Re: [Sks-devel] SKS peering request [sks-server.randala.com]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is why libc is required, I've tried to use sks-1.1.4 from trusty already, same set of dependencies. And as before, if I'm going to update libc, I might as well do a full dist upgrade. # dpkg -i libdb5.3_5.3.28-3ubuntu2_amd64.deb (Reading database ... 97168 files and directories currently installed.) Preparing to replace libdb5.3 5.3.28-3ubuntu2 (using libdb5.3_5.3.28-3ubuntu2_amd64.deb) ... Unpacking replacement libdb5.3 ... dpkg: dependency problems prevent configuration of libdb5.3: libdb5.3 depends on libc6 (= 2.17); however: Version of libc6 on system is 2.15-0ubuntu10.5. dpkg: error processing libdb5.3 (--install): dependency problems - leaving unconfigured Errors were encountered while processing: libdb5.3 https://help.ubuntu.com/ -- stable is 13.10, stable LTS is 12.04, 14.04 is devel, meaning not stable :-) And as I said, my prior experiences are full of grief with premature dist-upgrades. And I read somewhere on the internets that dist-upgrade isn't supposed to be stable until about 14.04.1. So, yeah, I may play with 14.04, but not on production machines. Unless there is a compelling reason. Is there? Is there a really good reason to move from 1.1.3 to 1.1.4? Martin On 04/06/2014 03:26 PM, Tobias Frei wrote: Hi, I don't really see why upgrading to the next stable release would make you a test-case, but I'm also already running 14.04 on my webserver, so I might be the wrong person to ask about this. :D If it helps (maybe the new libc version isn't required), you might want to download this package too: http://freiwuppertal.de/libdb5.3_5.3.28-3ubuntu2_amd64.deb I can also provide other current .deb files on request. Best regards, Tobias Frei Am 06.04.2014 12:49, schrieb Martin Papik: I am using the latest stable LTS, unfortunately, ubuntu LTS matures slowly and I've been bitten with premature dist-upgrades. I'll choose waiting over being a test-case. At least on anything that's exposed to the internet. # wget http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb # dpkg -i sks_1.1.4-2.1ubuntu1_amd64.deb (Reading database ... 97126 files and directories currently installed.) Preparing to replace sks 1.1.1+dpkgv3-7ubuntu0.3 (using sks_1.1.4-2.1ubuntu1_amd64.deb) ... Stopping sks daemons: sksrecon.. sksdb.. done. Unpacking replacement sks ... dpkg: dependency problems prevent configuration of sks: sks depends on libdb5.3; however: Package libdb5.3 is not installed. dpkg: error processing sks (--install): dependency problems - leaving unconfigured Processing triggers for ureadahead ... Processing triggers for man-db ... Errors were encountered while processing: sks # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=12.04 DISTRIB_CODENAME=precise DISTRIB_DESCRIPTION=Ubuntu 12.04.4 LTS Doesn't seem to work, I tried adding deb http://us.archive.ubuntu.com/ubuntu/ trusty main universe to /etc/apt/sources.list, but just installing sks would replace libc, which basically means I might as well dist-upgrade, which I won't do just yet. PS in my personal experience with the last ubuntu LTS increment, it will be stable enough sometimes next year. Until then, I'm afraid I only have three options, compile from sources (headache, error prone, extra maintenance), wait for someone to backport 1.1.4 on 10.4 or 12.4, or just leave it as 1.1.3. 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? Martin On 04/06/2014 12:07 PM, Tobias Frei wrote: Hi, if you'd be using the latest Ubuntu, you would probably also have access to the newest SKS version in the repositories. ;-) Ubuntu 14.04 LTS will come out soon; upgrading to that should give you 1.1.4. If your server is running on amd64, you can use this .deb for now, if you want to: http://freiwuppertal.de/sks_1.1.4-2.1ubuntu1_amd64.deb Best regards, Tobias Frei Am 05.04.2014 16:17, schrieb Martin Papik: Thank you, I've upgraded to 1.1.3, although why Ubuntu didn't install that one without an explicit parameter boggles me a bit. Oh well. Is that sufficient, or will I have to install the very latest from source? The web server is enabled, there's just no main page in the directory yet. I see Error fetching key from hash : Not_found messages in the log though, is this normal? The hashes update, so I'm not overly worried, just want to know if this is normal. Anyway, thanks again for taking the time to assist me. Martin On 04/05/2014 04:38 PM, BluKeyserver wrote: Hi Martin, Quoting from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 'Versions prior to 1.1.2 have a severe interoperability bug (POST requests for
Re: [Sks-devel] SKS peering request [sks-server.randala.com]
Thank you very much Jerzy, however I'm facing some problems. I wonder if you have any insight. I'm new to sks, but it seems to me that there might be an apache proxy intercepting the connections and interfering somehow. I don't see my server in http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but the sks servers are talking to each other on 11370 so I'm assuming there's some kind of asymmetric setup. Any help would be appreciated. Martin In the log I see (after incrementing http_fetch_size to 1000 to reduce the number of entries). 2014-04-05 08:43:40 address for keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET [176.241.243.15]:11370, ADDR_INET [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 54ABD9C187E4555DB2377ABFCD29D8B8 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 7E819BE55160DDBD06E480F74F1D6017 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with A7E5518397DB6A961E9FB8B59C1391D6 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with D348A85B40F5C08C3CA2E9AB09EF2CB0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 64 missing keys from ADDR_INET [176.241.243.15]:11371, starting with FD40B34ECD8971CFCECF9E79D48772F0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) The tcpdump output contains (looks like HTTP 0.9, no host header in the request, no HTTP headers in the response). Request to 176.241.243.15:11371 POST /pks/hashquery content-length: 24 Response from 176.241.243.15:11371 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title502 Proxy Error/title /headbody h1Proxy Error/h1 pThe proxy server received an invalid response from an upstream server.br / The proxy server could not handle the request ema href=/pks/hashqueryPOSTnbsp;/pks/hashquery/a/em.p Reason: strongError reading from remote server/strong/p/p hr addressApache Server at keyserver.kolosowscy.pl Port 80/address /body/html On 04/05/2014 04:21 AM, Jerzy Ko?osowski wrote: Hi, I added your server. My line to add: keyserver.kolosowscy.pl 11370 # Jerzy Kolosowski je...@kolosowscy.pl Rgds, Jerzy Ko?osowski Dnia s'roda, 2 kwietnia 2014 05:50:52 Martin Papik pisze: Hi everyone, I've just configured sks 1.1.1 (default on Ubuntu) on sks-server.randala.com. The machine has IPv6 but SKS has not yet been assigned an address. I wonder, is there an advantage (e.g. in terms of peering)? The server is located in Germany/EU. For now I'm deploying the server for RD as a proxy for my private server (behind my ISPs randomized NAT). You may contact me if you have further questions or for any issues, operational or otherwise. Loaded from: http://keys.niif.hu/keydump/ [2014-03-31? ... köszönöm] Loaded: 3583821 keys Line to add to /etc/sks/membership sks-server.randala.com 11370 Thank you. Martin ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel ___ 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: SHA1 Hi Martin, Quoting from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 'Versions prior to 1.1.2 have a severe interoperability bug (POST requests for exchanging keys are HTTP/0.9, does not work with modern setups having reverse HTTP proxies in front as a best practice.' Perhaps it's a time to ditch the 1.1.1 and try to compile 1.1.4 instead ? Also, I have noticed, that you did not enable the built-in www server: 'Page not found: /var/lib/sks/www/index.html' Regards, H.Storm [TheBluProject] On 05/04/2014 07:52, Martin Papik wrote: Thank you very much Jerzy, however I'm facing some problems. I wonder if you have any insight. I'm new to sks, but it seems to me that there might be an apache proxy intercepting the connections and interfering somehow. I don't see my server in http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but the sks servers are talking to each other on 11370 so I'm assuming there's some kind of asymmetric setup. Any help would be appreciated. Martin In the log I see (after incrementing http_fetch_size to 1000 to reduce the number of entries). 2014-04-05 08:43:40 address for keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET [176.241.243.15]:11370, ADDR_INET [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 54ABD9C187E4555DB2377ABFCD29D8B8 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 7E819BE55160DDBD06E480F74F1D6017 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with A7E5518397DB6A961E9FB8B59C1391D6 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with D348A85B40F5C08C3CA2E9AB09EF2CB0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 64 missing keys from ADDR_INET [176.241.243.15]:11371, starting with FD40B34ECD8971CFCECF9E79D48772F0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) The tcpdump output contains (looks like HTTP 0.9, no host header in the request, no HTTP headers in the response). Request to 176.241.243.15:11371 POST /pks/hashquery content-length: 24 Response from 176.241.243.15:11371 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title502 Proxy Error/title /headbody h1Proxy Error/h1 pThe proxy server received an invalid response from an upstream server.br / The proxy server could not handle the request ema href=/pks/hashqueryPOSTnbsp;/pks/hashquery/a/em.p Reason: strongError reading from remote server/strong/p/p hr addressApache Server at keyserver.kolosowscy.pl Port 80/address /body/html On 04/05/2014 04:21 AM, Jerzy Ko?osowski wrote: Hi, I added your server. My line to add: keyserver.kolosowscy.pl 11370 # Jerzy Kolosowski je...@kolosowscy.pl Rgds, Jerzy Ko?osowski Dnia ?roda, 2 kwietnia 2014 05:50:52 Martin Papik pisze: Hi everyone, I've just configured sks 1.1.1 (default on Ubuntu) on sks-server.randala.com. The machine has IPv6 but SKS has not yet been assigned an address. I wonder, is there an advantage (e.g. in terms of peering)? The server is located in Germany/EU. For now I'm deploying the server for RD as a proxy for my private server (behind my ISPs randomized NAT). You may contact me if you have further questions or for any issues, operational or otherwise. Loaded from: http://keys.niif.hu/keydump/ [2014-03-31? ... köszönöm] Loaded: 3583821 keys Line to add to /etc/sks/membership sks-server.randala.com 11370 Thank you. Martin ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org
Re: [Sks-devel] SKS peering request [sks-server.randala.com]
Thank you, I've upgraded to 1.1.3, although why Ubuntu didn't install that one without an explicit parameter boggles me a bit. Oh well. Is that sufficient, or will I have to install the very latest from source? The web server is enabled, there's just no main page in the directory yet. I see Error fetching key from hash : Not_found messages in the log though, is this normal? The hashes update, so I'm not overly worried, just want to know if this is normal. Anyway, thanks again for taking the time to assist me. Martin On 04/05/2014 04:38 PM, BluKeyserver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin, Quoting from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 'Versions prior to 1.1.2 have a severe interoperability bug (POST requests for exchanging keys are HTTP/0.9, does not work with modern setups having reverse HTTP proxies in front as a best practice.' Perhaps it's a time to ditch the 1.1.1 and try to compile 1.1.4 instead ? Also, I have noticed, that you did not enable the built-in www server: 'Page not found: /var/lib/sks/www/index.html' Regards, H.Storm [TheBluProject] On 05/04/2014 07:52, Martin Papik wrote: Thank you very much Jerzy, however I'm facing some problems. I wonder if you have any insight. I'm new to sks, but it seems to me that there might be an apache proxy intercepting the connections and interfering somehow. I don't see my server in http://keyserver.kolosowscy.pl:11371/pks/lookup?op=stats, but the sks servers are talking to each other on 11370 so I'm assuming there's some kind of asymmetric setup. Any help would be appreciated. Martin In the log I see (after incrementing http_fetch_size to 1000 to reduce the number of entries). 2014-04-05 08:43:40 address for keyserver.kolosowscy.pl:11370 changed from [] to [ADDR_INET [176.241.243.15]:11370, ADDR_INET [2002:b0f1:f30f::1]:11370] 2014-04-05 08:44:06 6064 hashes recovered from ADDR_INET [176.241.243.15]:11371 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 0005AB14802673F046EC31CC93AC36DC 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 29DF15D7EF250667DE9012CDF6891CE7 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 54ABD9C187E4555DB2377ABFCD29D8B8 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with 7E819BE55160DDBD06E480F74F1D6017 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:11 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with A7E5518397DB6A961E9FB8B59C1391D6 2014-04-05 08:44:11 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 1000 missing keys from ADDR_INET [176.241.243.15]:11371, starting with D348A85B40F5C08C3CA2E9AB09EF2CB0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) 2014-04-05 08:44:12 Requesting 64 missing keys from ADDR_INET [176.241.243.15]:11371, starting with FD40B34ECD8971CFCECF9E79D48772F0 2014-04-05 08:44:12 Error getting missing keys: Failure(!DOCTYPE HTML PUBLIC \-//IETF//DTD HTML 2.0//EN\) The tcpdump output contains (looks like HTTP 0.9, no host header in the request, no HTTP headers in the response). Request to 176.241.243.15:11371 POST /pks/hashquery content-length: 24 Response from 176.241.243.15:11371 !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title502 Proxy Error/title /headbody h1Proxy Error/h1 pThe proxy server received an invalid response from an upstream server.br / The proxy server could not handle the request ema href=/pks/hashqueryPOSTnbsp;/pks/hashquery/a/em.p Reason: strongError reading from remote server/strong/p/p hr addressApache Server at keyserver.kolosowscy.pl Port 80/address /body/html On 04/05/2014 04:21 AM, Jerzy Ko?osowski wrote: Hi, I added your server. My line to add: keyserver.kolosowscy.pl 11370 # Jerzy Kolosowski je...@kolosowscy.pl Rgds, Jerzy Ko?osowski Dnia ?roda, 2 kwietnia 2014 05:50:52 Martin Papik pisze: Hi everyone, I've just configured sks 1.1.1 (default on Ubuntu) on sks-server.randala.com. The machine has IPv6 but SKS has not yet been assigned an address. I wonder, is there an advantage (e.g. in terms of peering)? The server is located in Germany/EU. For now I'm deploying the server for RD as a proxy for my private server (behind my ISPs randomized NAT). You may contact me if you have further questions or for any issues,
