How much load are keyservers willing to handle?
Hi, I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. Cheers, adrelanos [1] http://lists.debian.org/debian-security/2013/12/msg00031.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
On Wed, Dec 18, 2013 at 10:20:26PM +, adrelanos wrote: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. [1] http://lists.debian.org/debian-security/2013/12/msg00031.html 1) setup your own DNS so you can shut things off if anything goes wrong! (you can use dyn.com or others, no servers required) 2) probably best discussed on the sks-devel list, Reply-To set accordingly 3) try running your own keyserver(s), SKS is easy enough to deploy -- Jason Harris | PGP: This _is_ PGP-signed, isn't it? jhar...@widomaker.com _|_ Got photons? (TM), (C) 2004 pgpya6iSgyHv5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The question I have is, What problem are you trying to solve? I am certain that Debian Security already has a protocol in place for how to handle compromised certificates. Is this protocol flawed or lacking? What problem does it not address which this idea will solve? The next question is, Why is it important the certificate be retrieved from the keyserver network? When talking about the global apt repositories, it's likely they have access to multiple of orders of magnitude more bandwidth than the keyserver network. Why not host the signing key on the apt repo server? Could keyservers cope up with the load? Good question. Probably, but some keyserver operators might view it as rude. Best to ask on sks-de...@nongnu.org. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert J. Hansen: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The question I have is, What problem are you trying to solve? What in case the apt signing key gets compromised. What is the mechanism of invalidating the client's keys so they can't fetch malicious files from any mirrors. I am certain that Debian Security already has a protocol in place for how to handle compromised certificates. Certainty is what sometimes makes the world an unsafe place. I would have supposed that this is the case as well, but after verifying such suppositions I was often quite surprised. Is this protocol flawed or lacking? It is non-existent. See my original question [1] and also in my current discussion [2] someone would have stepped in and said we already have this. Since this didn't happen and since I also looked through apt's sources, I am certain this thing doesn't exist. Can't prove it though, Russell's teapot you know. ;) What problem does it not address which this idea will solve? When there is reason to believe, the apt signing key has been compromised, the revocation certificate can be spread through a channel other than apt updates (which are compromised). The next question is, Why is it important the certificate be retrieved from the keyserver network? It's not important. I didn't mean to say that. It's just simpler to code (for me, in the draft in my head). And if they don't mind, I'll go the easy way, if they mind, I'll come up with another solution. When talking about the global apt repositories, it's likely they have access to multiple of orders of magnitude more bandwidth than the keyserver network. Yes. Why not host the signing key on the apt repo server? They could of course re-use their existing mirror network for this. Could keyservers cope up with the load? Good question. Probably, but some keyserver operators might view it as rude. Best to ask on sks-de...@nongnu.org. Will do. [1] http://lists.debian.org/debian-security/2013/10/msg00065.html [2] http://lists.debian.org/debian-security/2013/12/msg00031.html -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJSsmssXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v26MP/R1TMYHHE6l0Ayhs6qZS3iGf fKDKM8qVfJUo/YBxAaYXVtfD6Ovs4jgKR7KXvy/xzsq4XdoDWMEgsZG3MLP+JiyS j3g7BEVns+55A/vPDysMUstrwQPhSBklnA+my3QG4UnDdKUjx8/m3jxWbMphe+sj fdMtOAquRCj72dIgtiYSYCfOnb9UN7EaEWrIyK57c9J5ygD6HTOjU4VoNKwLfHnf W8IAeTv4N1PDZIZ/dPteDkBYuCdgJgB+QAYh7yJ5AuCV1dhiTkip92PkE3+tCVHs /mufO9Ffy3mAtsD7U0H6Mq2rCqa8v3tHpraMROHdyuyAK1VJqbfveOkeKHjL2ocZ 2uJbAF/m/JmQFLPH/+V8siItg2qhYS2I6qhxE5RvS1FmbwPf/yvulSQQmaNJNPLE pxR7LbOAS9zUfJsy44r+t4n6N64qDmEBk6g+tRLMpn0MC8zfdSvZBxxWP9JVkWc1 C8JHeluKH8jrQbbLSBeG9Ie8WUMSmJpqfQLI6jK6sW2zXRA11VSSFNyPB48vsuZB 9kUtJ7ido0/npI/225JN/oQJ3RaTKj62OyDQSW8X4C4gMWFj8EZAvoSj/nKiKUtB RH1IJ8GBCsK1QR5Biia/KchYlAW+HKpJpOrn6C8Wm+ubBooYuK7csud5exWZLS+Q VAq22Rq6RdgitL1O/4OJ =O6my -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jason Harris: On Wed, Dec 18, 2013 at 10:20:26PM +, adrelanos wrote: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. [1] http://lists.debian.org/debian-security/2013/12/msg00031.html 1) setup your own DNS so you can shut things off if anything goes wrong! (you can use dyn.com or others, no servers required) Interesting idea. I guess in that case I'll got with what I wrote under 3). 2) probably best discussed on the sks-devel list, Reply-To set accordingly Okay, I'll repost there. 3) try running your own keyserver(s), SKS is easy enough to deploy I don't have a lot servers with bandwidth available. And rather than spending money on that, in case keyservers decline, I am probably re-using sourceforge.net's infrastructure. I already asked them once about a similar thing [they're willing to host our project news files (comparable small files with comparable load)], they'll most likely accept that as well. I don't know how they or some others manage it, but their traffic comes virtually for free. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJSsmskXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7vRloP/i0vZRFCyQY7NBc1ZxPuVJpA PPiKuXODo/+jG/VX8krkYWaAIL9otCwrUMFlS0LxFYHvtfx03NaISaGG1WV3mWJA 1KiqODX+5RszCf/By4tW9JE1EdNeOjZM+XhPZ6oRMQogpmtVAe1EFIscQ84H3k0T SOcd4I//Q+7qkomhEu+C0crSogzzyvYRhG52a7IGDUCLRrhAc+CX0WbYqc5OZj5c qHGdDMPbhpa0/Z514pYuewUu4tQDc3NLZ1fpZGd6GeY3zC/grrLEtnbQogkjeiwB nIu90TC5yYGw8B9reJlfb6lq6s+QG/bs6yweHVg4oaa/i7Lfe9O6/WMshshuu62z sMt3eyAeXTyKFYPv9kugSFNkqGHWlDome3PJzYOqRE3BkxYU21qegzTfNUD50jpH pNVX5I7wSecpvNa3yIEE9000FDOdwvx/sJrEhmlY90J12BHZATJHQgcgq04GAPQT OL+kYRhifdS6BE7VXT2eHepQzviGScPZ09n+5ZpkX6nn/pcW84McUYg3qpam8OoU hGmcoJ0V5dnGNJjmzdMfeej1TsYKjE+uWpAod/lPnXHry/4FYTTSxrdfyfaRQOJx yd2DkcjZ0EzP/13DS8GxgH53FKiqxIQxjDhVyBNeSVnjB/f6TbuMJH3ZEl0FL3gn /ex0cwPRQ6lVxLtcpg8f =/K1w -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
