Re: [Sks-devel] status page
Hi, maybe you need to send a correct Via: header to allow automatic detection of the reverse proxy. If proxying is done completely transparent, there is probably no way to see that there is actually a proxy in front of sks. That's what I would assume, at least. Best regards, Tobias Frei Am 17.04.2014 16:20, schrieb Simon Lange (BIT): well, but there IS a reverse proxy. ;) tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN 8804/lighttpd tcp0 0 127.0.0.1:11371 0.0.0.0:* LISTEN 10018/sks tcp6 0 0 2a01:4f8:201:22e3:11371 :::* LISTEN 8804/lighttpd Am 2014-04-17 15:56, schrieb Tobias Frei: Hi, from the status page you've linked: Latest status: Not OK Reason: Not running a reverse proxy Best regards, Tobias Frei Am 17.04.2014 01:13, schrieb Simon Lange: Hi, im a it supprised. i just stumbled over: https://sks-keyservers.net/status/info/keys.s-l-c.biz which says that my keyserver was last seen three days ago. im not enlisted anymore and the status page cannot even say what server im running etc etc im a bit wondered. why? i can reach it via 11370 11371 and 443 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz --search-key m...@simonlange.eu gpg: searching for m...@simonlange.eu from hkp server keys.s-l-c.biz (1) Simon Lange m...@simonlange.eu 2048 bit RSA key BDD503BE, created: 2009-09-04 Keys 1-1 of 1 for m...@simonlange.eu. Enter number(s), N)ext, or Q)uit works like charme. via browser? see attachment (screenshot). works too. ;) recon works too 2014-04-17 01:12:04 Beginning recon as server, client: ADDR_INET [162.243.102.241]:59001 2014-04-17 01:12:04 Joining reconciliation 2014-04-17 01:12:04 Reconciliation complete 2014-04-17 01:12:04 2 hashes recovered from ADDR_INET [162.243.102.241]:11371 2014-04-17 01:12:04 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:04 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04 Disabling gossip 2014-04-17 01:12:14 Requesting 2 missing keys from ADDR_INET [162.243.102.241]:11371, starting with 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys received so why is my server not enlisted anymore? what are the exactly port protocols you are checking?! id like to prevent such a status page although keyserver is still up n running. oO thanks for your help Simon ___ 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
Er, sorry, I see you already do that. Then maybe the automatic detection failed for whatever reason. And I just noticed that your status changed to OK. Weird^^ Best regards, Tobias Frei Am 18.04.2014 13:30, schrieb Tobias Frei: Hi, maybe you need to send a correct Via: header to allow automatic detection of the reverse proxy. If proxying is done completely transparent, there is probably no way to see that there is actually a proxy in front of sks. That's what I would assume, at least. Best regards, Tobias Frei Am 17.04.2014 16:20, schrieb Simon Lange (BIT): well, but there IS a reverse proxy. ;) tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN 8804/lighttpd tcp0 0 127.0.0.1:11371 0.0.0.0:* LISTEN 10018/sks tcp6 0 0 2a01:4f8:201:22e3:11371 :::* LISTEN 8804/lighttpd Am 2014-04-17 15:56, schrieb Tobias Frei: Hi, from the status page you've linked: Latest status: Not OK Reason: Not running a reverse proxy Best regards, Tobias Frei Am 17.04.2014 01:13, schrieb Simon Lange: Hi, im a it supprised. i just stumbled over: https://sks-keyservers.net/status/info/keys.s-l-c.biz which says that my keyserver was last seen three days ago. im not enlisted anymore and the status page cannot even say what server im running etc etc im a bit wondered. why? i can reach it via 11370 11371 and 443 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz --search-key m...@simonlange.eu gpg: searching for m...@simonlange.eu from hkp server keys.s-l-c.biz (1) Simon Lange m...@simonlange.eu 2048 bit RSA key BDD503BE, created: 2009-09-04 Keys 1-1 of 1 for m...@simonlange.eu. Enter number(s), N)ext, or Q)uit works like charme. via browser? see attachment (screenshot). works too. ;) recon works too 2014-04-17 01:12:04 Beginning recon as server, client: ADDR_INET [162.243.102.241]:59001 2014-04-17 01:12:04 Joining reconciliation 2014-04-17 01:12:04 Reconciliation complete 2014-04-17 01:12:04 2 hashes recovered from ADDR_INET [162.243.102.241]:11371 2014-04-17 01:12:04 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:04 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04 Disabling gossip 2014-04-17 01:12:14 Requesting 2 missing keys from ADDR_INET [162.243.102.241]:11371, starting with 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys received so why is my server not enlisted anymore? what are the exactly port protocols you are checking?! id like to prevent such a status page although keyserver is still up n running. oO thanks for your help Simon ___ 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
Hi, On 04/17/2014 04:20 PM, Simon Lange (BIT) wrote: well, but there IS a reverse proxy. ;) tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN 8804/lighttpd If I remember right, the monitor checks for a 'VIA' header. See https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering for the configuration of several proxe servers. Arnold ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I don't know who maintains the monitor, but this email chain prompted me to have a quick look at the differences between the responses between a reverse proxy and SKS and I found a few differences and how to detect a reverse proxy. I've come up with two other ways to detect a reverse proxy (other than the Via header). Maybe the Via header is important for some other part of the protocol I'm not aware of, i.e. for the client to detect and report who actually handled the request, but here goes. Method 1, request HEAD for the status page lynx -mime_header -head -source 'http://xxx:11371/pks/lookup?op=stats' A reverse proxy responds with 502 proxy error and lynx returns with no error (0), SKS cuts the connection without returning any headers (which causes the proxy error), in which case lynx exits with error (1). Method 2, intrusive, connect to port 11371, request status via a new connection and see if it completes. Method 2 is useless in practice, but method 1 might give additional information. Maybe distinguish between a well configured reverse proxy and a badly configured reverse proxy. Martin On 04/18/2014 02:30 PM, Tobias Frei wrote: Hi, maybe you need to send a correct Via: header to allow automatic detection of the reverse proxy. If proxying is done completely transparent, there is probably no way to see that there is actually a proxy in front of sks. That's what I would assume, at least. Best regards, Tobias Frei Am 17.04.2014 16:20, schrieb Simon Lange (BIT): well, but there IS a reverse proxy. ;) tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN 8804/lighttpd tcp0 0 127.0.0.1:11371 0.0.0.0:* LISTEN 10018/sks tcp6 0 0 2a01:4f8:201:22e3:11371 :::* LISTEN 8804/lighttpd Am 2014-04-17 15:56, schrieb Tobias Frei: Hi, from the status page you've linked: Latest status: Not OK Reason: Not running a reverse proxy Best regards, Tobias Frei Am 17.04.2014 01:13, schrieb Simon Lange: Hi, im a it supprised. i just stumbled over: https://sks-keyservers.net/status/info/keys.s-l-c.biz which says that my keyserver was last seen three days ago. im not enlisted anymore and the status page cannot even say what server im running etc etc im a bit wondered. why? i can reach it via 11370 11371 and 443 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz --search-key m...@simonlange.eu gpg: searching for m...@simonlange.eu from hkp server keys.s-l-c.biz (1) Simon Lange m...@simonlange.eu 2048 bit RSA key BDD503BE, created: 2009-09-04 Keys 1-1 of 1 for m...@simonlange.eu. Enter number(s), N)ext, or Q)uit works like charme. via browser? see attachment (screenshot). works too. ;) recon works too 2014-04-17 01:12:04 Beginning recon as server, client: ADDR_INET [162.243.102.241]:59001 2014-04-17 01:12:04 Joining reconciliation 2014-04-17 01:12:04 Reconciliation complete 2014-04-17 01:12:04 2 hashes recovered from ADDR_INET [162.243.102.241]:11371 2014-04-17 01:12:04 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:04 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04 Disabling gossip 2014-04-17 01:12:14 Requesting 2 missing keys from ADDR_INET [162.243.102.241]:11371, starting with 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys received so why is my server not enlisted anymore? what are the exactly port protocols you are checking?! id like to prevent such a status page although keyserver is still up n running. oO thanks for your help Simon ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTUWX2AAoJELsEaSRwbVYr3JcQAKhu4yfDqsQu+U1xBxnlVTeC GTzQ4VqjegE4Khc2FW6xvuyFtqRt7pgUDBmGDveQ5KW+/UdrAaGeVT/i/XZFlUBx ewD58zm+gtiRndlWM7GGSjRDcoHrSBjIC3o+TR6iL49T9FkSpHOgl9y08Tg2oD25 pQRSIoeaAOEVGXQRSoD6XulEoT0TBURotTHPya3R6vY4XKYVRU/jylhVT3i75wih 2SP5OMLpRrLarOkaUc2+Z/NRYsFEXdfZV4RSQwawC2tFKMiSg5VCzjGWOqPY61AZ IMgbO9qV3aFG/6Odj3A+fAGKAsQOJUgo0OofivScfSKxlLfTQ/N+nyyCauWJI0EQ s48l5QdQrkYpgT+bA0w8uOumeEmta4TmyHa3gHVOrQTsxf+9758E1CtEuQnDZJl+ 3umFYQnWe3B/VTi8vHBvuoERIVjBElJkAMW8GhrnvnN87WH2zVwHuTvOR1kbGPKP eAchpOhYeMpW1703aDZwT4R0ISBcBdt1ad67GUbnqiQfDFQPhMWVGz6DjolIdXWb IuBpokgwzF4qoiKECvw3LWJxjUAFepuhJ7lKETXlXe7dWCI6/lOuhkDT9JC84DmU 7K47/YOn065rqDbx5XGNMNRvf1vyFWhE3cwcoccnOf0xpS3WIAVNGVnLFcOekqMo TJBAuBHd9rYGDWAPjFwT =A8Ol -END PGP
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, after directly communicating with Kristian via twitter i could enlight the whole situation. first. the whole process lacks of rudementary technical documentation. second. if the requirement is a reverse proxy and there is one, but your script fails. then blame the script. otherwise declare exactly what you want to check and what you expect to get. a transparent proxy is still a proxy. the reason why a reverse proxy is required is, because some require additional security at the nodes. useless to tell, that its not their biz nor their construction site. anyhow, in my case i did provide a reverse proxy, which is listening exactly to that hostname i did provide too as gossip on this mailing list. ;) yesterday i learned i have to give up control who is using his domain with my services. :/ currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and if kristian or someone else wants to join the server for their pool to id recommend the same kindness as for gossip. tell them explicitly that you want to use their service so give them the chance to add their domain too not requiring allowing the whole world to user their all domains using our services. its a matter of respect AND security. its an optin feature not a optout. this is the same for the reverseproxy (11371). there is absolutely no reason for a via (which may exposes the used software) or a global allow to the whole world to use all existing FQDNs to use that specifiy service. dont allow anyone except fqdn which did ask before is far more secure. (e.g. i dont want any raccist website to advertise with MY services under THEIR domain, but because i cannot KNOW all such domains, its better to deny all and allow a few). third. never mix technical documentation with ANY advertisement/pr texts just telling how cool how nice how fast how whatssoever the service is. an admin wants techdoc not PR. ;) this is not a rant, but maybe sounds rude to some. hope i could explain what my point is. i like techdoc which explains the WHOLE process. i hate not having techdoc or incomplete techdoc and getting information waterdrop-wise. thats all. best regards Simon PS: as the status page says its working now. if you want to put my tcp/11371 tcp/80 on your proxy/lb, tell me the fqdn you may use. i put them in. yes, i will disable the allow all setting in the next couple of days again. Am 18.04.2014 19:50, schrieb Martin Papik: I don't know who maintains the monitor, but this email chain prompted me to have a quick look at the differences between the responses between a reverse proxy and SKS and I found a few differences and how to detect a reverse proxy. I've come up with two other ways to detect a reverse proxy (other than the Via header). Maybe the Via header is important for some other part of the protocol I'm not aware of, i.e. for the client to detect and report who actually handled the request, but here goes. Method 1, request HEAD for the status page lynx -mime_header -head -source 'http://xxx:11371/pks/lookup?op=stats' A reverse proxy responds with 502 proxy error and lynx returns with no error (0), SKS cuts the connection without returning any headers (which causes the proxy error), in which case lynx exits with error (1). Method 2, intrusive, connect to port 11371, request status via a new connection and see if it completes. Method 2 is useless in practice, but method 1 might give additional information. Maybe distinguish between a well configured reverse proxy and a badly configured reverse proxy. Martin On 04/18/2014 02:30 PM, Tobias Frei wrote: Hi, maybe you need to send a correct Via: header to allow automatic detection of the reverse proxy. If proxying is done completely transparent, there is probably no way to see that there is actually a proxy in front of sks. That's what I would assume, at least. Best regards, Tobias Frei Am 17.04.2014 16:20, schrieb Simon Lange (BIT): well, but there IS a reverse proxy. ;) tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN 8804/lighttpd tcp0 0 127.0.0.1:11371 0.0.0.0:* LISTEN 10018/sks tcp6 0 0 2a01:4f8:201:22e3:11371 :::* LISTEN 8804/lighttpd Am 2014-04-17 15:56, schrieb Tobias Frei: Hi, from the status page you've linked: Latest status: Not OK Reason: Not running a reverse proxy Best regards, Tobias Frei Am 17.04.2014 01:13, schrieb Simon Lange: Hi, im a it supprised. i just stumbled over: https://sks-keyservers.net/status/info/keys.s-l-c.biz which says that my keyserver was last seen three days ago. im not enlisted anymore and the status page cannot even say what server im running etc etc im a bit wondered. why? i can reach it via 11370 11371 and 443 proof? simon@entertain:~$ gpg --keyserver hkp://keys.s-l-c.biz --search-key m...@simonlange.eu gpg: searching for
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/18/2014 09:24 PM, Simon Lange wrote: yesterday i learned i have to give up control who is using his domain with my services. :/ Please explain, I'm not aware of such a requirement and if there is such I would like to know about it so I can make informed decisions. Thank you Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTUXpKAAoJELsEaSRwbVYr3h0P/1WxLYp/T7TIMP64CAMx6nJe oXJ7yWvH+xj7eWOQxgjixFhU7/b6gR4n97ghFShQpfB948Va/op9MCVxEPn9QuRZ XUaQ/5goeYqs3lJGQI0sKrXT0ONiM92xn+PwIvp8ub8bTBTAuvDjif9SeB8YRiO4 dTwF3AirIqkU4VFQ4Dy9VIR755EiUmDl1MW8ab/j5vqGNgKVFi/RVc/nrXVAhwGF MQXLMtSjs2Y5QeeF80tw0TWDABjfHWy+hHoWGT9jtKOPMFs4jw/L7oIDyNJBgoxO 4ZMuypP1vNdlERAH6Ff7vka9im14cWk8K39dAb7R8BGqg3FatJ84ViuOELZ84xuB njuN8b41xaJQWDGdLRfagM+b8Dj0CsiLakr4ZJDuEcjfIFqOEsoQ/iYCWeL3vVVJ 6TeQda9YPIHHk3FUNFnMLkHBsHF8cI25LWLx3JmXR/XaAiEUvxg1EX97HfJOmKqS YdHpW/K+JyZHUA417uf8mk6l+XCWKzusQWM/5UCM+6s2Gp1j8lKFvlCiN4ILRK7B TdZraH5eHaPtKjlH1arnnz44dWupPhQfc7xH2sSxH2GDkIKQChOYJrct+BxVWaSZ U1bsljUTo/scaoMGHYBXHWWADtxyYawBQ4A7MRjXFyfbGneFMhfEm7Qmgvcq2pm8 nMjizNxoziiGRR2V7Auk =K+9K -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.04.2014 21:18, schrieb Martin Papik: On 04/18/2014 09:24 PM, Simon Lange wrote: yesterday i learned i have to give up control who is using his domain with my services. :/ Please explain, I'm not aware of such a requirement and if there is such I would like to know about it so I can make informed decisions. Ive been told that it is required to allow ALL incoming traffic to the IP of my keyserver for port 11371 no matter what hostname is requested. that would - of course - allow everyone on this planet to pinpoint his FQDN to my server using my service. usually i use hostname directives. e.g. keys.s-l-c.biz or keys.bundes.it or (.*)pool.sks-keyservers.net i prefer that because that way i can avoid that ppl use my services with their fqdn i dont like (like raccists facists and other bad ppl). i opened it temporaly so we are enlisted in the pool again. but in a couple of days i close that door again allowing ONLY those fqdm who did contact me before. so i got at least a minimum control who is using my services with their fqdn and who not. ;) in a couple of days the fqdn written above will work. others not. Thank you Martin best regards Simon - -- Simon Lange Consulting - Gaudystr. 6 - DE-10437 Berlin Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160 - http://s-l-c.biz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUX7qAAoJELCfvQa91QO+bjEH/j+j1Y7EUXVNqkQrEi0QLOxt 6387q2q9LuC8c+Kpa4EgZJLB6Tpptedz31y+bq+hhN53qmoNy6a2mNV399MY0iDa Sx5khJ7gd5713vJCNlGuiyfK4Hz4NdoHZPMyVKu/2B9p1Od4LHehukGNmCAAQDS5 LyNRMlqy9cMXz+YijLrL5gvZ597YML1fbA3aTottCfbm2AJGXiSBxYvZiL/apJvl T24nDR60CndUEbsKp/O4IjZiBFQvZdVKjRxzik1ujx4ahUfcs1AFfWZrO6vORAlV xVqWJJDAWns5Pdi/VmevWDS7H6HIo/onQ8ZuLHqqA7HRnQiTDdFPJgEzRi/QxMw= =DV8h -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/18/2014 10:37 PM, Simon Lange wrote: Ive been told that it is required to allow ALL incoming traffic to the IP of my keyserver for port 11371 no matter what hostname is requested. that would - of course - allow everyone on this planet to pinpoint his FQDN to my server using my service. usually i use hostname directives. e.g. keys.s-l-c.biz or keys.bundes.it or (.*)pool.sks-keyservers.net i prefer that because that way i can avoid that ppl use my services with their fqdn i dont like (like raccists facists and other bad ppl). You of course can (should?) limit the HTTP host names to whatever you expect, but I've never heard of a requirement to answer ALL host names. A response to the raw IP address would be probably good, but are you really required to answer http://blablabla/ on tcp/11371? I've never heard about such a requirement. Not beyond answering requests for the pool host name if you wish to participate in a pool. Answering ALL host names just makes you willing to participate in any pool by default, without extra maintenance. But again, AFAIK this isn't a requirement. Am I misinformed? How would bad people benefit from your key-server responding to http://very.bad.com:11731/ anyway? AFAIK today the key server doesn't serve arbitrary pictures, when it will this will be an issue, more because of spam I expect than on account of nasty web sites. Does lighthttpd (which you seem to be using) expose some kind of a forward proxy? Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTUYaMAAoJELsEaSRwbVYrXEAQALUBEBCbREvfHQ5DdZ8ZPrc/ H+kiZ88CBoPiMVL/RtZGW7hfgKg5A3b/4VcxtHrqgABPEwmUNoDKRuG9VBtR/Xjd BU4/5/Wxkw0cXgrFT8MeUXpRQIbeq7PT0R2RyM3wDGhLmeh9TtW6EEDrhtVcgVJo MC2VCLwbz6STSYOlMxUD1epecFLsZLVXPSHVS3bH89As3H1MfK2V7vofk8Z7cEhZ dhBOlY8F198N9E+meF9C+vWinjHMFSCSvNWnS8RkhFj7TLKKUOdBetVtiYndm8fO o7Ij+srvT3uITjbHBVJN4L1JAuUh6WDurmHPVNwwIWEVqFH2joeoHDCmUaLvZmUp 170cM5ym9weDNJVJFipA2W0CkFG9x+KZBK6PyeDB/+KSrthCZSsCRw3/VNCzXKr8 xwSawnmdnyoJTf3iPbWD8sHKo4Q3TC4lhlNDV6k+roFroZTgLS+vhHxRz9tzTmou c3X/yyENwqByoR326RybXRUE3j8hGHgrBkmUM6MTAzWGQRfnzWd9I1ERIP36GY20 OKNmt4qbHWpsRdy1Mj3JD34vslTraqoSG9SAm5Qjh+tPQwRjPL6zaQ9RSQ0k1bqe xQOkpqOmSDx0eKxkggU9OtqTbScFIEqMR8iW2oAfUVnQsVaMEV2Gy+aZXXDCgGLR 3XYwG6DRlT3DaQn6unk5 =Dc7u -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
Hi, sorry for my naivity, but I can't really think of a scenario where it would be a problem that your PGP keyserver (and only that one, keys.s-l-c.biz) is accessible under any other domain name. If your keyserver is accessible at insert-racist-domain-name-here.tld, so what? Does that make you a racist? Does that make the keyserver racist? I personally don't really get that logic. Best regards, Tobias Frei Am 18.04.2014 21:37, schrieb Simon Lange: i prefer that because that way i can avoid that ppl use my services with their fqdn i dont like (like raccists facists and other bad ppl). i opened it temporaly so we are enlisted in the pool again. but in a couple of days i close that door again allowing ONLY those fqdm who did contact me before. so i got at least a minimum control who is using my services with their fqdn and who not. ;) in a couple of days the fqdn written above will work. others not. smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.04.2014 22:10, schrieb Martin Papik: Answering ALL host names just makes you willing to participate in any pool by default, without extra maintenance. But again, AFAIK this isn't a requirement. Am I misinformed? https://twitter.com/krifisk/status/456717051340791808 With a HTTP Host header not belonging to the specific hostname? Note the -H 'Host.' , 11371 should allow ALL traffic through How would bad people benefit from your key-server responding to http://very.bad.com:11731/ anyway? bad ppl could pretend offering a public service using my machines they dont own nor they administre nor they run. my machines would support that passivly. think this is easy to understand. and also has some legal implications. just imagine feds want to seize all machines of some bad ppland pinpoint using the IPs the get from running services under badppl's domains... not worth the risk while easy to avoid. we dont gossip with everyone without handshaking first. i keep it that way same with the pool. :) Does lighthttpd (which you seem to be using) expose some kind of a forward proxy? only if i ask him to. ;) if i run him transparently the pool-check-script fails and says that i dont run a reverse proxy. ;) Martin Simon - -- Simon Lange Consulting - Gaudystr. 6 - DE-10437 Berlin Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160 - http://s-l-c.biz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUY4/AAoJELCfvQa91QO+KyEH/iOzvCXkYlkAbyz8vZP4e6xm eSI8wvt+F8KDh/zdgw8Dk5iw2cEMOqYrob/JwmrvSXML+mpipIbUE5r0zXNy25PB kkxQOxbvkM6btJSQA+tkvRNJMlT/RDLuJySSGIMumUAcNQJVfqySWHaqxw2YhEol daEDjfNzMxnxj+QCdDKf8zNtQUhqkcqSEdRRyhyZVtnmsOQopmngRZSNGVil8ipV NCXc6Oo0X6ghwPXtgtkczK91/2Po5lfTfqsBXBVAH4XJvrE0JQnhGo5RL7/sZ0MY ECZMPS6DEHwbo5hpqoqsINheCYpC6yiQyazCUwxURHvqdNwbt7XXGpePluEJIZM= =1kAW -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
im afraid gpg wont show that while using it. ;) but for the webinterface its valid. ;) but i see you understand now my problem. ;) Simon Am 18.04.2014 22:38, schrieb Tobias Frei: Hi, simply add this page is served by keys.s-l-c.biz; I am in no way affiliated with other hostnames which might resolve to this IP or something like that to the page then? Best regards, Tobias Frei Am 18.04.2014 22:31, schrieb Simon Lange: it gives those bad ppl a benefit. because they can pretend running a public service although they dont. and i would passivly support them with my machines doing that. thats a nogo for me. see? Simon Am 18.04.2014 22:26, schrieb Tobias Frei: Hi, sorry for my naivity, but I can't really think of a scenario where it would be a problem that your PGP keyserver (and only that one, keys.s-l-c.biz) is accessible under any other domain name. If your keyserver is accessible at insert-racist-domain-name-here.tld, so what? Does that make you a racist? Does that make the keyserver racist? I personally don't really get that logic. Best regards, Tobias Frei Am 18.04.2014 21:37, schrieb Simon Lange: i prefer that because that way i can avoid that ppl use my services with their fqdn i dont like (like raccists facists and other bad ppl). i opened it temporaly so we are enlisted in the pool again. but in a couple of days i close that door again allowing ONLY those fqdm who did contact me before. so i got at least a minimum control who is using my services with their fqdn and who not. ;) in a couple of days the fqdn written above will work. others not. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel -- Simon Lange Consulting - Gaudystr. 6 - DE-10437 Berlin Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160 http://s-l-c.biz ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/18/2014 11:42 PM, Simon Lange wrote: https://twitter.com/krifisk/status/456717051340791808 With a HTTP Host header not belonging to the specific hostname? Note the -H 'Host.' , 11371 should allow ALL traffic through Sounds more like a recommendation than a requirement. At least to me. Maybe he'll chime in to clarify. How would bad people benefit from your key-server responding to http://very.bad.com:11731/ anyway? bad ppl could pretend offering a public service using my machines they dont own nor they administre nor they run. my machines would support that passivly. think this is easy to understand. and also has some legal implications. just imagine feds want to seize all machines of some bad ppland pinpoint using the IPs the get from running services under badppl's domains... not worth the risk while easy to avoid. we dont gossip with everyone without handshaking first. i keep it that way same with the pool. :) Feds aren't stupid. Your machines wouldn't support anything, and they'd merely be more victims of criminals. Personally I don't see this as an argument. Otherwise you could say that merely having a public IP puts you at risk of having your servers seized because anyone can point their domains at them. On the other hand if your servers already contain something that might be interesting to the feds, you might be in trouble and you should be cautious. If you're worried, maybe you should contact the feds to find out what puts you at risk of HW seizure. :-) After all, I'm not qualified to give you legal advice. Merely expressing my personal opinion. Good luck. Martin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTUZfMAAoJELsEaSRwbVYr86MQAJpuB/hsVtiJGtMNEQElzmtu cTrHEWz9HyfjDtTzJVD7OXMSTeIxBXx2yDvtNSvjbWq0jGYd6F93TtGMyHlYAdw7 +O7kvn0H8C/AfwzXKk+cqyaB0Mxr7r1OP2GV0o7WOYK6X6V8h8ZmWm2sqMnY/fMt DxdZriLCs5VaKPZ6bnzhojRQQhP44pdCMH/Lj+RSPUYEiFyppjpb7uI6faU4fBgy C2TNU1qZ+YdFsLUTRZGv6yeZuE3zRVVqWclq1y8pVPG7+5QqIzJkPpCK/kiSLNkU G6IacjVpCv51luTQb4hM5s7kH70DpF9ZiHIw9dqM0A/Cc8fs5EwA9jHD2L4Q4IX1 XF5ttLVy4FOCxjhkVzF5TgcpQ5i35HErJpqS+eylIya63MTIO8jzEynL7r6K16Rg mqDmYLMaReK2Br3mMk4I+FcDmNsrgGV2pBpqn2mvRk9djex8ynm7Tyu1rDnxU9oO Ec5eO1rWTwYlauAtGsD0rz4Wf+72CL+2EFRvQ8h13Ac2FTncMYemupvAzQxiAfAq IbV0GTHYEgTRUv5UWmMdaJfhQYxi0aYucih6/JwveTLZf7G9dn4l0l5c33565sk0 0XcdpVeAkgFXqB3Jjio+L7ETc/kQ0KRUs0Oo+gU83Ze8UxmXBqu2v7A2AqS9Umgl pifHjO3Zwp04LWUh7/xA =VpKj -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-04-18 at 20:24 +0200, Simon Lange wrote: the reason why a reverse proxy is required is, because some require additional security at the nodes. False. The SKS software is single threaded and handles a single request at a time. One client can hold open a connection and prevent anyone else from using your server. Anyone can run a pool definition, using whatever criteria they like. There is no requirement to be in any pool. Equally, there is no requirement for anyone else to peer with you. If you can find people willing to peer with you while you don't work to fit in any pools, then that's okay -- nobody but you and your peers has any business telling you what to do. So far, mostly, keyserver operators have been willing to add peers without checks for pool-worthiness because so far, mostly, new community members have worked to be members of the main pools, so there has been no need. Kristian's pools list only keyservers which he thinks are suitable to be listed as defaults for end-users. The rules change over time as we learn and develop; Kristian has always clearly communicated changes to this mailing-list. Amongst other things, his requirements include keyservers which won't hang because some other client is holding open a connection, so that the keyservers are not going to be seen as broken, never working, leading end-users to disable PGP. Other requirements include up-to-date, able to peer reliably, not so buggy as to cause interop problems, and more. yesterday i learned i have to give up control who is using his domain with my services. :/ False. As long as you can find people who will peer with you, you do not need to be in any pools at all. currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and Note that Kristian's pool is considered well-run and is used as the target of CNAMEs by other people. Most notably, `keys.gnupg.net` is a CNAME to `pool.sks-keyservers.net`. So if you only whitelist for a pattern which, when unbroken, is: ^(?:.+\.)?pool\.sks-keyservers\.net then you've broken access by people using the default configuration of GnuPG. Kristian doesn't want those people to experience a broken service, so you don't get listed. Kristian _could_ decide to only support certain CNAMEs, then exhaustively test for all of those working, then going through the song-and-dance of de-listing most sites when he adds one more CNAME. Instead, he just says to be listed in my pools, then on port 11371, all HTTP requests under `/pks/` should be passed to SKS, no matter what is in the Host: header. This creates less stress, less bureaucracy, less of a culture of having to ask permission for every action. domains using our services. its a matter of respect AND security. its an optin feature not a optout. Absolutely: you don't need to be listed in a pool, there is no hard requirement for it. _I_ won't give away _my_ bandwidth for free to provide others with keys if they're not giving back to the community by being listed in public pools. That's my choice, in not subsidising other peoples' businesses and hobbies from my own pocket more than I already do with my time on open source projects. That's okay. You and I don't have to peer. There is no one right way, no authority saying everyone must peer, no right to peering, no expectation that everyone agree. You can probably find other people who will peer with you. (11371). there is absolutely no reason for a via (which may exposes the used software) It helps debug operational problems. When you ready the configuration advice on: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering you're reading the results of that debugging, as we've found various problems and confirmed that avenues of debugging were correct, looking around at other keyservers. Speaking as someone who has helped debug a few major issues and done most of the writing for that document, I'm grateful to those who make it easy for others to work with them instead of demanding that permission be requested before knowing what's going on. I'll certainly spend far more of my time debugging servers which are candidates for Kristian's pool and which make data available than I will on other servers. You don't need to expose full version, but revealing Apache/2 provides enough for most debugging. If revealing even that much makes you vulnerable, then you have bigger problems, because more intrusive platform fingerprinting by those of malicious intent will identify your platform anyway. FQDNs to use that specifiy service. dont allow anyone except fqdn which did ask before is far more secure. (e.g. i dont want any raccist website to advertise with MY services under THEIR domain, but because i cannot KNOW all such domains, its better to deny all and allow a few). Go ahead, use that policy. Find others who agree, create pool
Re: [Sks-devel] status page
On 04/18/2014 04:42 PM, Simon Lange wrote: bad ppl could pretend offering a public service using my machines they dont own nor they administre nor they run. my machines would support that passivly. think this is easy to understand. and also has some legal implications. just imagine feds want to seize all machines of some bad ppland pinpoint using the IPs the get from running services under badppl's domains... not worth the risk while easy to avoid. we dont gossip with everyone without handshaking first. i keep it that way same with the pool. :) I'm sorry, but this concern is not related to SKS; this is the way the internet works. Here's another example, not related to SKS: If you reverse the string illuminati and then append .org, and put it in your web browser, you will find yourself instead at the homepage of an organization that probably does not want themselves to be publicly affiliated with the illuminati. The nature of the SKS pool is that different people address it in different ways. for example, there are sub-pools that your keyserver might be part of, and they each have different names. There are also other well-known names (like keys.gnupg.net) that themselves are aliased to the pool. If you want your SKS instance to work with the various labels and pools that are available, you will let your SKS instance be addressed by arbitrary names. If you don't want your SKS instance to participate in the pool, you don't need to answer to different names. that's fine too; but please don't accuse the pool coordinator (kristian) of setting up these rules to make trouble for you or any other keyserver operator; rather, he's trying to make it so that people who rely on any of the pools (directly or indirectly) will always reach a functioning keyserver. If you don't want to be in the pool because you don't want to take the same risk that every other web site takes, that's OK; you can still sync keys with members of the pool, but your keyserver won't be queried by people using the pool. hope this helps explain the reason behind this requirement. --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.04.2014 23:16, schrieb Phil Pennock: On 2014-04-18 at 20:24 +0200, Simon Lange wrote: the reason why a reverse proxy is required is, because some require additional security at the nodes. False. ehm. nope. thats is what ive been told when i asked y the reverse proxy. ;) but good to know. :=) yesterday i learned i have to give up control who is using his domain with my services. :/ False. As long as you can find people who will peer with you, you do not need to be in any pools at all. thats not the topic. and its rude btw. currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and Note that Kristian's pool is considered well-run and is used as the target of CNAMEs by other people. Most notably, `keys.gnupg.net` is a CNAME to `pool.sks-keyservers.net`. So if you only whitelist for a pattern which, when unbroken, is: ^(?:.+\.)?pool\.sks-keyservers\.net then you've broken access by people using the default configuration of GnuPG. Kristian doesn't want those people to experience a broken service, so you don't get listed. and that is written where exactly? see? thats why i req techdoc?! but keys.gnupg.net is already covered too. ;) Kristian _could_ decide to only support certain CNAMEs, then exhaustively test for all of those working, then going through the song-and-dance of de-listing most sites when he adds one more CNAME. Instead, he just says to be listed in my pools, then on port 11371, all HTTP requests under `/pks/` should be passed to SKS, no matter what is in the Host: header. This creates less stress, less bureaucracy, less of a culture of having to ask permission for every action. allowing ALL is not a really good option. i already explained y. and a page with techdoc which hostnames should be allowed is not much. y using less procedure for pool reg than for gossip? whats the point with this? because less bureaucracy? less stress? i dont think its much stress and bureaucracy to tell ppl what hostnames should be able to use the service. domains using our services. its a matter of respect AND security. its an optin feature not a optout. Absolutely: you don't need to be listed in a pool, there is no hard requirement for it. right and you dont need to learn anything anymore since u know everything. oh wait. ;) try being less rude and try please to follow arguments. _I_ won't give away _my_ bandwidth for free to provide others with keys if they're not giving back to the community by being listed in public pools. That's my choice, in not subsidising other peoples' businesses and hobbies from my own pocket more than I already do with my time on open source projects. that just proved that you didnt understand anything i wrote. this is not against good ppl. you dont protect your servers and your environment against good ppl. you protect it against bad ppl. so hard to understand?! and exactly THATS WHY i dont allow fqdn like keys.npd.de to use my keyserver. i dont support racist or inhuman parties/organizations. if you dont care for your community. okay. but for ppl who do care, its a maybe a problem to allow those ppl to advertise with services which are not run by them. all others are invited. gimme a short notice and i put them on. thats the concept of optin. this is how you configure firewalls too. deny all and tell whats allowed. in this case easy to do. thats why i really dont unerstand ur attitude. That's okay. You and I don't have to peer. There is no one right way, nobody talks about peering. m) no authority saying everyone must peer, no right to peering, no expectation that everyone agree. m) You can probably find other people who will peer with you. you dont get it. the topic is NOT peering. m) (11371). there is absolutely no reason for a via (which may exposes the used software) You don't need to expose full version, but revealing Apache/2 provides enough for most debugging. If revealing even that much makes you vulnerable, then you have bigger problems, because more intrusive platform fingerprinting by those of malicious intent will identify your platform anyway. you are derailing the topic. FQDNs to use that specifiy service. dont allow anyone except fqdn which did ask before is far more secure. (e.g. i dont want any raccist website to advertise with MY services under THEIR domain, but because i cannot KNOW all such domains, its better to deny all and allow a few). Go ahead, use that policy. Find others who agree, create pool definitions which tightly control which final hostnames can be used. you repeating urself. try arguments and read. Kristian has made his pool software freely available for others to use: https://code.google.com/p/sks-keyservers-pool/ I have made my own pool software freely available for others to use:
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.04.2014 23:39, schrieb Martin Papik: By the way, Phil's email explains why it's required, and now I understand why it's a true requirement, at least for servers in the pool. For non pool servers it doesn't matter. since i only talked about the pool. well... phil just proved that he didnt understand anything. however hes not topic here. that STRONGLY depends where you living. i could tell you days filled with stories about really stupid feds seizing servers raiding homes by mistake. never underestimate them and why risking something when its not required to achieve a goal? ;) Are the German feds stupid and/or aggressive? Or are you referring to a different country? it even depends where in germany you are living. try to avoid berlin. ;) - -- Simon Lange Consulting - Gaudystr. 6 - DE-10437 Berlin Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160 - http://s-l-c.biz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUcH1AAoJELCfvQa91QO+tH0IAMjJFLiil+xlIkwpDrGtma35 EU7WILkvLOeBmx6VGLM6HmoHn3gmJEUbS2Ctk399JEAes608vqHCwM5ge1bnE7fG dVxOi5k7VErT+ijfMe3Qd3pYhYAnaWrP8s9HaqmkLosqxgdMQExI4y2wc5WvyCuT OotPHrrRZ9muzphnbj0zLx0laNOVozd2tT3LCQB/IRx+AllHm9hl6Mywtfmk5+oQ f7YHWa5TMxLkDs+/b7WcRNlX5BwxZtEH1wfR9L+//Pnjvp2+802DS+6sDyP4zFGq cd70UVnLHgiRsE5Va0YV27OAX2AB/EgT8Lhc8gUHJdQs0l7O9QDQ4W7s77qYuv4= =F2zd -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 18.04.2014 23:24, schrieb Daniel Kahn Gillmor: On 04/18/2014 04:42 PM, Simon Lange wrote: bad ppl could pretend offering a public service using my machines they dont own nor they administre nor they run. my machines would support that passivly. think this is easy to understand. and also has some legal implications. just imagine feds want to seize all machines of some bad ppland pinpoint using the IPs the get from running services under badppl's domains... not worth the risk while easy to avoid. we dont gossip with everyone without handshaking first. i keep it that way same with the pool. :) I'm sorry, but this concern is not related to SKS; this is the way the internet works. ehm, nope. the decision what content my machines do deliver under which hostname ist not how the internet works. its a decision of the admin of the machine. sure, you can use your hostname resolving my ip but that does not mean that you get the same content as if someone tries to use a hostname which has a directive to show that content. Here's another example, not related to SKS: If you reverse the string illuminati and then append .org, and put it in your web browser, you will find yourself instead at the homepage of an organization that probably does not want themselves to be publicly affiliated with the illuminati. ?! are you sure you did understand my point? that example does not make any sense. The nature of the SKS pool is that different people address it in different ways. for example, there are sub-pools that your keyserver might be part of, and they each have different names. There are also other well-known names (like keys.gnupg.net) that themselves are aliased to the pool. yeah but that is not the point. If you want your SKS instance to work with the various labels and pools that are available, you will let your SKS instance be addressed by arbitrary names. not really. i decide what pool i may want to be in. gnupg and sks-keyservers are okay. but that is not an invitation to allow the rest of the world to pinpoint their FQDN to my service-ip using it under their name. i did even reason why this is not a good idea. by now noone told me a good reason to take the risk instead of gently asking. If you don't want your SKS instance to participate in the pool, you don't need to answer to different names. that's fine too; but please don't accuse the pool coordinator (kristian) of setting up these rules to make trouble for you or any other keyserver operator; rather, he's acusing? m) i did suggest not to require a no matter what hostname comes policy. i did suggest he writes what his check-script is checking so admins may configure their servers in a way to fullfill his needs. THATS less stress. getting information drop by drop is ineffective and more stress. sure, he can ignore it. on the other hand i wouldnt ignore it if would be him. because some good documentation (techdoc) would avoid many questions many threads and many time answering them. ;) trying to make it so that people who rely on any of the pools (directly or indirectly) will always reach a functioning keyserver. If you don't want to be in the pool because you don't want to take the same risk that every other web site takes, that's OK; you can still sync keys with members of the pool, but your keyserver won't be queried by people using the pool. again. its not a matter of the pool. its a matter y allowing OTHER fqdn than the sks-keyservers pool to access under their fqdn?! is it really so hard to understand? hope this helps explain the reason behind this requirement. i see the luxury point but not why not changing it and why not documentating the requiremnts of his check-script. --dkg Simon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUcW6AAoJELCfvQa91QO+43cH/0uKtzsPrLobdinyhS6Q8qzk M0+hGp7zaN9XPgzrv2QPoh5ptIwErou9kx33XTR39XZgTPbBfZmv5QttcRp3EbDq 75/MT3lomkgZHVnHu7FeGTuRhdx5ntTHMkXQKARWLWK1FlKt15DfarVpGAJJBaG8 N/YMmSbjUeIuVRHJoM2Mer6DLSFrLEaQAlBz3KKpYCJjVZ5CNdvcqFtFnbJ5ib+7 mGShy6NvdLoucu1OVHS35gW0MqDqve540rfNyORWQdLZuyyMLZTb3mYPKJLM2J9g n/CM9QyzBkD6eoFZNvU8ioVz6GXs5QcRd9mmZx4yH5p4+7HtOtu+scnTGY+zXp4= =ynWh -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] status page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2014-04-19 at 02:21 +0200, Simon Lange wrote: Am 18.04.2014 23:16, schrieb Phil Pennock: -Phil *PLONK* Could someone please do me a kindness and pass on a message to Mr Lange? Maintaining a keyserver peering requires the ability to communicate, because each peer is able to cause operational problems for the other. If we can't communicate, I am unwilling to peer because when problems happen, they can't be resolved. So applying a killfile rule (which is what plonk means to me) while maintaining a peering is deeply problematic. Thus I have removed the line for his keyserver from the membership file of my keyserver. Thanks, - -Phil -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJTUgyYAAoJEKBsj+IM0duFIecH/j25Kewr6MY6HBa8QPzpLFff H+Zrmu3yZujeEWKCIyCflrsjsOrOrN2dwr3nhK3zgkRHurCAGDB2+iQkHFey30O4 j/N8z/oNKq/kZdvB1fsDtO6O4YU3LrzKHvVVWc3jDqmA77SpSKsQP1AQ84GiwF8U evtqF+qeu7LankiwPqy5KWABETRAfiy1L6/olqclVGgGxWWzSldUi+JVY8HY1Zpg 4znz43oUStyTnv1xKzzlHwQD+5VGx+vmEbRQ1T0QynMf5II/P7E8z0smKG4RaSsC lAAxg0kj5SpaFMc8Dwv8RY5Zbw5BfDoxLiIax2W5QlelSgh07WxZWFbsJX8CrJw= =GYhD -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
