-----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 definitions which tightly control which final hostnames can be used. 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: https://github.com/philpennock/sks_spider You have two platforms available for you to run pools using whatever criteria you like. Go for it. Just don't expect anybody to take you seriously if you try telling us what criteria we are *allowed* to use for our own pools. > this is not a rant, but maybe sounds rude to some. It was a rant. Your claiming otherwise did not make it not a rant and did not change it from being a set of demands on how others work, on how others should change what they do to suit you, how you get control over what other people can do and how they can communicate. Thank you for making your keyserver usable by the pools. I may strenuously disagree with your stance and your demands, but as long as you're providing a public service, I'm happy to continue peering with you. If you change your mind about providing a public service which can be freely listed by anyone, please do let me now and I will remove your system from my peering membership list. - -Phil -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJTUZYZAAoJEKBsj+IM0duFWqcH/A170Yy4ttcrpOe9WxMIvZqQ EJmt2KoYnI/N1Ln+dN9hlMqhXwV1JxFosQaJBRvQdTonaLbtukowYKsSBN/gGggG 7E1bj5q9ronjABNXdtIwFMEeT3P1+WJyAbKEr5KdIR6OPG+h543w97DXeMsJCgOP 6nxIXnJB64/9DyH1J1zeS4fH+Dqse1ZI7mO3/NadESfOrgEvPhwr4D/TK4pCqDQu AznUuvpjzOfnSk0iurtP3l8HdS9lIIhJh5bFHgGvC7tlJtedL516XHcK+0iVSji1 9Iw/JRPNKhjB09Wv2uAvOFfWNn+LA+YTUudlEGJAx35x1JjSIwpJEFyxiFM052A= =0dPE -----END PGP SIGNATURE----- _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel