Re: Desperately Seeking Kristian - SKS HKPS certificate renewals
On 23.06.2020 09:24, Stephan Brunner wrote: > Hey, > > maybe you can try your luck on facebook: > https://www.facebook.com/kristian.fiskerstrand > > Seems he was last active in late march... Can't guarantee that it really > is him, but as a last resort it could help.. Thats me, but I'm around here, just focusing on everything else than computers lately, sorry about that (but it has really been nice..) Will get around to issuing a new certificate for you (todd) later today or tomorrow. (p.s , as for expired openpgp cert it was sent to sks network, but should also be avalable fresh copy through wkd) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature
Re: Debian sks.service: Main process exited, code=killed, status=11/SEGV
On 26.02.2020 13:10, Azamat S. Kalimoulline wrote: > Hi. After recon started with peer sks crashed with message in logs > "sks.service: Main process exited, code=killed, status=11/SEGV". No other > messages in logs. SKS version 1.1.6 Debian Buster. Is anyone get that? > > > I'd guess it hitting a stack limit during merge of a large key. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature
Re: hkps.pool.sks-keyservers.net DNS failing to resolve
On 15.01.2020 19:19, Todd Fleisher wrote: > Thanks for the update, it looks like DNS recovered shortly after this > message was sent. However, I’m still seeing an expired CRL > @ https://sks-keyservers.net/ca/crl.pem Yes, I cheated and disabled the check for the pool (no certs are revoked for any actual issues anyways), but won't get around to actually updating the crl until this evening or more likely tomorrow as that requires special access. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature
Re: hkps.pool.sks-keyservers.net DNS failing to resolve
On 15.01.2020 02:28, Todd Fleisher wrote: > Hopefully Kristian finds and fixes his issue in the morning. thanks for the heads up everyone; should be back up on next update run (cause: crl expired) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws signature.asc Description: OpenPGP digital signature
Re: cant build dabase
On 13.12.2019 00:56, Skip Carter wrote: > correction, the errors are stackoverflows not segfaults > ulimit -s unlimited before building. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws
Re: [Sks-devel] Status page problem
On 23.08.2019 06:13, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > This screenshot was created this morning. (Cca. 04:00 UTC) > http://bakacsin.ki.iif.hu/~kissg/tmp/sks-pool_screenshot.png Thanks for reporting, that's curious... > > Regards > > Gabor > -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] Sks-devel Digest, Vol 184, Issue 26
Just use unlimited to test, you can monitor actual size through proc for the pid to determine a proper value, but I haven't done the exercise myself On August 22, 2019 6:19:03 PM GMT+02:00, Jason John Schwarz wrote: >OK, that is where I was adjusting it on my system, and ulimit -s is >showing the increase properly...maybe I just haven't made it large >enough. >I am up to 16384 now. I was hesitant on going to unlimited. Any >suggestion on value, or are you running it in unlimited mode? > >Jason John Schwarz >Chief Technical Officer >MSC Inc > >eMail: ja...@insect.com <mailto:ja...@insect.com> >Phone: (910) 689.0557 > (800) 284.7872 >Fax: (910) 689.0558 > > > >> On Aug 22, 2019, at 12:14 PM, Kristian Fiskerstrand > wrote: >> >> On 22.08.2019 18:08, Jason John Schwarz wrote: >>> I am seeing the same issue on the insect.com server. Where is the >>> stack size setting, because I have not been able to find it for SKS? >> >> Depends a bit on init system , so you'd have to check documentation >for >> your system. But traditionally you specify it on a per user basis in >> /etc/security/limits.conf . See also man ulimit for a one-off, e.g >> ulimit -s unlimited before starting sks. >> >> -- >> >> Kristian Fiskerstrand >> Blog: https://blog.sumptuouscapital.com >> Twitter: @krifisk >> >> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net >> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 >> >> Corruptissima re publica plurimæ leges >> The greater the degeneration of the republic, the more of its laws >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Sks-devel Digest, Vol 184, Issue 26
On 22.08.2019 18:08, Jason John Schwarz wrote: > I am seeing the same issue on the insect.com server. Where is the > stack size setting, because I have not been able to find it for SKS? Depends a bit on init system , so you'd have to check documentation for your system. But traditionally you specify it on a per user basis in /etc/security/limits.conf . See also man ulimit for a one-off, e.g ulimit -s unlimited before starting sks. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] Shutting down keyserver.zap.org.au
Fwiw, that error sounds like too small stack size for the process - in an alternative universe it would be interesting to hear your experience running with a higher stack limit On August 21, 2019 9:16:05 PM GMT+02:00, John Zaitseff wrote: >It is with feelings of sadness and regret that I will be shutting >down keyserver.zap.org.au, effective immediately, purging all >associated database files and logs. I will be sending out >individual emails to my current peers as well. > >I have enjoyed being part of the SKS community since May 2014. >Thank you for all your help during that time! But good things often >come to an end... I had hoped to be "last one standing" :-) but >that is not to be. > >For the record, I am not shutting my server down because something >better has come along -- although keys.openpgp.org is a start. It's >just that my current installation began core-dumping on a regular >basis since last week (segfault error 6 -- write to an unmapped >address). I've been running a cron job every fifteen minutes to >restart the daemons, but that was only a stop-gap measure. >Recreating the databases using a fresh key dump did not help. And >given the current state of the SKS network, it just wasn't worth >bothering about debugging the root cause. > >All the best, everyone! > >Yours truly, > >John Zaitseff > >-- >John Zaitseff ,--_|\The ZAP Group >Telephone: +61 2 9643 7737 / \ Sydney, Australia >Email: j.zaits...@zap.org.au \_,--._* https://www.zap.org.au/ > v > >___ >Sks-devel mailing list >Sks-devel@nongnu.org >https://lists.nongnu.org/mailman/listinfo/sks-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] extending status pages
See Membership fileSee reference membership file On July 30, 2019 9:51:31 PM GMT+02:00, "Kiss Gabor (Bitman)" wrote: >Dear Kristian, > >I have a suggestion about status pages. >Would you mind to provide information about what other hosts >consider a given server as a peer? > >I mean it could be a third HTML table on bottom of page >https://sks-keyservers.net/status/ks-status.php?server=SOME.HOSTNAME.HERE >titled as "Referred by" or so. > >Also the JSON object provided by >https://sks-keyservers.net/status/ks-status-json.php?server=SOME.HOSTNAME.HERE >could be extended with list of referring servers. > >Actually this info is public but it is quite tiresome to rake it >together. :-) >Meanwhile your monotoring program already collects all the data >I wish to see. > >Regards > >Gabor -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS initial key load issue
My guess is you need to increase stack size On July 28, 2019 5:37:58 PM GMT+02:00, Marcin Gondek wrote: >Hello All, > >Can someone help me or instruct why every time I do initial key load >i'm getting always getting segfault? >I've tried with many dump and always is the same. >MD5 are ok about pgp files with dump. > >[1568590.382715] sks[5476]: segfault at 7ffee91cdff8 ip >00524320 sp 7ffee91ce000 error 6 in sks[40+176000] >[1596334.117959] sks[18454]: segfault at 7fff75083ff8 ip >00525cb2 sp 7fff75084000 error 6 in sks[40+176000] >[1599235.574487] sks[9543]: segfault at 7ffc09407ff8 ip >00525c04 sp 7ffc09408000 error 6 in sks[40+176000] >[1599972.656642] sks[20023]: segfault at 7ffca5d80ff8 ip >00525c04 sp 7ffca5d81000 error 6 in sks[40+176000] >[1603395.657126] sks[16808]: segfault at 7ffe59903ff8 ip >00524320 sp 7ffe59904000 error 6 in sks[40+176000] >[1617152.333123] sks[24992]: segfault at 7ffcfdec4ff8 ip >00525c04 sp 7ffcfdec5000 error 6 in sks[40+176000] >[1626758.189429] sks[6744]: segfault at 7ffcfaf27ff8 ip >00524320 sp 7ffcfaf28000 error 6 in sks[40+176000] > >17:13:35-root@fido:/srv/sks$ /usr/bin/sks build -n 5 -cache 512 >dump/*.pgp >Loading keys...done >DB time: 1.34 min. Total time: 1.36 min. >Loading keys...done >DB time: 0.24 min. Total time: 0.26 min. >Loading keys...done >DB time: 0.23 min. Total time: 0.26 min. >Loading keys...done >DB time: 0.25 min. Total time: 0.53 min. >Loading keys...done >DB time: 0.24 min. Total time: 0.27 min. >Loading keys...done >DB time: 0.25 min. Total time: 0.61 min. >Loading keys...done >DB time: 3.42 min. Total time: 3.46 min. >Loading keys...done >DB time: 0.31 min. Total time: 0.56 min. >Loading keys...done >DB time: 0.33 min. Total time: 0.48 min. >Loading keys...done >DB time: 1.23 min. Total time: 1.42 min. >Loading keys...done >DB time: 0.31 min. Total time: 0.58 min. >Loading keys...done >DB time: 0.87 min. Total time: 1.05 min. >Loading keys...done >DB time: 0.31 min. Total time: 0.53 min. >Loading keys...done >DB time: 0.32 min. Total time: 0.55 min. >Loading keys...done >DB time: 0.31 min. Total time: 0.52 min. >Loading keys...Segmentation fault > >17:36:22-root@fido:/srv/sks/KDB$ ll >total 6303152 >-rw---. 1 root root 352256 Jul 28 17:14 __db.001 >-rw---. 1 root root 29917184 Jul 28 17:26 __db.002 >-rw---. 1 root root 536870912 Jul 28 17:26 __db.003 >-rw---. 1 root root 5050466304 Jul 28 17:26 key >-rw---. 1 root root 67895296 Jul 28 17:26 keyid >-rw---. 1 root root 1024 Jul 28 17:15 meta >-rw---. 1 root root 63963136 Jul 28 17:26 subkeyid >-rw---. 1 root root 63242240 Jul 28 17:26 time >-rw---. 1 root root 1024 Jul 28 17:13 tqueue >-rw---. 1 root root 734728192 Jul 28 17:26 word >17:36:22-root@fido:/srv/sks/KDB$ du -h >6.1G. >17:36:24-root@fido:/srv/sks/KDB$ > >Thanks, > > >-- >Marcin Gondek / Drixter >http://fido.e-utp.net/ >AS56662 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Website down
Yes, it is a scheduled power outage and should be back up soon, the pool itself functions but wont update in the window. On July 10, 2019 1:29:29 PM GMT+02:00, "Kiss Gabor (Bitman)" wrote: >Dear Kristian, > >I wonder if you know that https://sks-keyservers.net/ is unreachable? > >Regards > >Gabor -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Gossip protocol mentor?
On 8/26/16 5:34 PM, Daniel Roesler wrote: > Howdy all, > > I've read through the academic paper several times, but I'm having a > difficult time going from the math to the code in the actual sks-keyserver. > Is anyone who knows the actual implementation details and mechanics of the > gossip protocol willing to be a mentor as I learn it? I'd like to just have > someone I can ping with questions as I work through the code. > > Thanks, > Daniel A lot of information can be gained by looking at the hockeypuck keyserver implementation, of which SKS recon is implemented in the conflux libary and documentation. https://hockeypuck.github.io/ https://gopkg.in/hockeypuck/conflux.v2 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] The pool is shrinking
On 6/21/19 2:43 PM, Daniel Roesler wrote: > I'd love to keep my server in the pool consistently, but until > Issue #61 is resolved[1], my server will spike to 100% CPU for > several minutes and become unresponsive as it tries to deal with > the huge troll keys. Sure, but this isn't an issue if you have multi-node cluster as the other servers will never recon at the same time, hence the requirement for hkps. > Running a server in the pool is no longer > a hobby project, and you have to constantly be restarting or > reconfiguring your server to keep it running. Not that much, but you need at least 8 GiB of RAM allocated for each node and sufficient swap or recon will often get OOM-killed. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] The pool is shrinking
On 6/21/19 6:53 AM, Kiss Gabor (Bitman) wrote: > Dear Kristian, Hi Gabor, > > At this moment there is only 27 members of pool.sks-keyservers.net. > And no more than 3 HKPS server are enlisted. > It is a real possibility that this number drops below 1. > Below 2 is actually the minimum for it to operate due to some gnupg internals. But it is relatively stable on 3-4. > Don't you want to revise your strict policy about issuing certificates? No, issuing certificates to servers not being able to keep up doesn't improve the experience from anyone (the number of complaints I get from users has dropped significantly). And its not really a strict requirement, one can set up VMs / chroots for it on a relatively small server. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] understanding error message
Have you run sks cleandb during setup phase? The setup scripts should include
it..
On June 4, 2019 3:38:38 AM GMT+02:00, Skip Carter wrote:
>my recon logs have messages like these:
>
>
> error in callback.: Failure("configuration of
>remote host () rejected: filters do
>not match.\n\tlocal filters: [ yminsky.dedup ]\n\tremote filters: [
>yminsky.dedup yminsky.merge ]")
>
> callback timed out.
>
>What do they mean and what do I do about them ? What are these filters
>? Is there something else I need to configure ?
>
>--
>Dr Everett (Skip) Carter
>s...@taygeta.com
>
>Taygeta Scientific Inc
>607 Charles Ave
>Seaside CA 93955
>831-641-0645 x103
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
On 5/27/19 4:39 AM, Phil Pennock wrote: > hkps is limited because Kristian doesn't hand out certs to anyone who > shows up with a new keyserver and asks; he tends to do so with people > who've been around and part of the community, because of the fairly > obvious problems with assuming TLS is buying you anything when entirely > unknown-to-others folks run the servers. Kristian takes a lot of flak > for not giving people the power they want just because they ask for it. > > With the various problems of SKS today, I tentatively suggest that not > defaulting to the HKPS pool and choosing a different target for the > keys.gnupg.net CNAME might be beneficial. Adding some meta-info to this one. In addition to the above-mentioned concerns about new actors (in particular those not part of strong-set), it is also a question of capacity of the keyservers, so hkps pool is requiring load-balanced setup with minimum of 3 nodes on modern hardware (e.g a node today requires a minimum of 8 GiB of RAM to be responsive during merge of certain keys). The propagation time between the servers in the broader pool became quite big and servers dropping in-out sporadically due to merges. Now, this is somewhat better for the general pool since https://dev.gnupg.org/T4175 results in retry on failover for 5xx codes, but has caused a lot of problem reports in the past and not all distros ship this in stable versions. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] IPv6 status
On 4/25/19 9:10 PM, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > According to > https://sks-keyservers.net/status/ks-status.php?server=keys.niif.hu > my server has not IPv6 connectivity. However I'm pretty sure it has. :-) > Could you check this problem? Sure its not blocked by firewall or something? curl "http://[2001:738:0:600:216:3eff:fe02:42]:11371/pks/lookup?op=stats"; .. times out from the system ipv6 tests are done on -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] DNS broken for hkps.pool.sks-keyservers.net
On 3/18/19 3:58 PM, Todd Fleisher wrote: > The GNUPG-users post mentions something that may be the root cause: > The status page for sks-keyservers.net shows no hosts are currently > available via hkps but other ports are available. > https://sks-keyservers.net/status/ <https://sks-keyservers.net/status/>I’m > speculating here, but if whatever Kristian users to update the DNS for > hkps.pool.sks-keyservers.net <http://hkps.pool.sks-keyservers.net/> doesn’t > think there are any valid nodes available perhaps it doesn’t publish any > records. This would result in NXDOMAIN. Given that pool.sks-keyservers.net > <http://pool.sks-keyservers.net/> & na.pool.sks-keyservers.net > <http://na.pool.sks-keyservers.net/> & others are still resolving properly I > don’t think it’s an EDNS issue. > > Adding Kristian directly in case he filters sks-devel mail. > Well, its a simple enough issue. the CRL expired, so no host validated anymore.. Services should be returning to normal soon enough. Thanks for the ping. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] Data protection concern[Ref. RFA0751305]
On 3/8/19 3:19 PM, Andrew Gallagher wrote: > On 08/03/2019 14:15, Kristian Fiskerstrand wrote: >> The ICO has concluded in this case and no further action will be taken >> from them. > > Was there any legal reasoning attached to this decision? It was a relatively good summary of situation including the data being shared voluntarily and the nature of the keyserver gossipping network also containing nodes being outside of the reach of GDPR. An important factor in the treatment is however timely response to erasure request with sufficient information. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] Data protection concern[Ref. RFA0751305]
On 2/19/19 6:13 PM, Kristian Fiskerstrand wrote: > Hi, > > In order to get a fruitful dialogue on these matters, some > clarifications regarding the role of the sks-keyservers.net pool of > keyservers seems necessary. > The ICO has concluded in this case and no further action will be taken from them. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] SKS scaling configuration
On 2/25/19 6:37 PM, Todd Fleisher wrote:
>> On Feb 23, 2019, at 8:35 PM, Jeremy T. Bouse
>> mailto:jeremy.bo...@undergrid.net>> wrote:
>>
>> I didn't have as many locations configured as you show in your example
>> but it looked like you were defining the map but I didn't see it being
>> used in any of your location blocks unless I'm missing something.
>> Shouldn't you be using $upstream_server in your proxy_pass configuration?
>>
> I think you’re on to something here. I just tried commenting out the
> other servers from the upstream sks_servers_primary block and am still
> seeing stats queries hitting the commented out servers.
>
> Kristian - could you please double check the configuration snippets you
> provided to me last year and see if something was missing related to this?
don't recall the specifics of the snippets I sent over, but the above is
correct, you do map definition at
map $arg_op $upstream_server {
"stats" sks_servers_primary;
default sks_servers;
}
which is used for
location /pks/lookup {
proxy_cache backcache;
proxy_ignore_headers Cache-Control "Expires";
#proxy_cache_bypass $http_cache_control;
add_header X-Proxy-Cache $upstream_cache_status;
proxy_cache_valid any 10m;
proxy_pass http://$upstream_server;
proxy_pass_header Server;
add_header Via "1.1 keys2.kfwebs.net";
proxy_ignore_client_abort on;
}
}
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
Corruptissima re publica plurimæ leges
The greater the degeneration of the republic, the more of its laws
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] Data protection concern[Ref. RFA0751305]
> > We would also like you to provide the following information: > > * Details of how you have handled this request for erasure. > > * Details of why Mr Hughes did not receive a response from SKS > Keyservers when exercising his rights. > > * Details of the organisation’s retention notice (as it would seem > that this is not on the website). > > * Details of SKS Keyservers’ lawful basis for processing this data and > why it is disclosing individuals’ –including Mr Hughes’– data > publically. > > * Details of any safeguards in place to help ensure you handle > personal data properly, particularly in relation to this specific > matter. > > * Details of any steps you have taken to add to or strengthen these > safeguards. > > > For your reference I have attached evidence that supports Mr Hughes’ > data protection concerns pertaining to his personal data. > > On a separate note, we would like to see a copy of SKS Keyservers’ > privacy policy to ensure that the organisation is compliant with its > information rights and practices. This is because, it would appear that > there is not a privacy policy on the website and this is an obligation > under the new legislation, to inform its users, transparently, that the > organisation is processing information that acts accordingly with GDPR > and the Data Protection Act 2018 (‘DPA’). > > You must provide this response as soon as possible and in any event > within *14 days*. > > If you do not provide the information we have requested, we will either > base our decision on the information available or consider issuing an > Information Notice. > > *Advice and assistance* > > Our website contains advice and guidance about the processing of > personal data and an organisation’s obligations under the Data > Protection law. I recommend that you review the information on our > website before finalising your reply. > > Should you wish to discuss this case any further, or require any > clarification, please do not hesitate to contact me. > > Yours sincerely > > Ryan Garner > Case Officer > Information Commissioner’s Office > 0330 414 6876 > > *ICO Statement* > You should be aware that the Information Commissioner often receives > request for copies of the letters we send and receive when dealing with > casework. Not only are we obliged to deal with these in accordance with > the access provisions of the data protection framework and the Freedom > of Information Act 2000, it is in the public interest that we are open > and transparent and accountable for the work that we do. > > For information about what we do with personal data see our privacy > notice at www.ico.org.uk/privacy-notice > <http://www.ico.org.uk/privacy-notice> > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws Email sent 29/5/18: Date: Tue, 29 May 2018 13:24:17 +0100 Subject: GDPR Erasure Request From: Dean Hughes To: kristian.fiskerstr...@kfwebs.net Dear Kristian, please find below a request exercising the GDPR right to erasure. I would be grateful if you would remove the following keys from your servers and storage devices and other third-party services with which your service shared this personal data. These records contain personal data that identify me as an individual pub 1024D/43AC5195 1998-11-25 Key fingerprint = 95BD F734 73C7 569E 5BDA CB78 1E21 55B4 43AC 5195 pub 1024D/6206C662 1997-12-20 Key fingerprint = AB92 4165 BCA2 7335 31F8 D1CC A353 ED76 6206 C662 pub 1024D/332B560B 2006-04-27 Key fingerprint = 3C7F FF39 CA2B 8022 0475 ECF2 C2F2 0E7B 332B 560B pub 1024D/826DB190 2001-11-18 Key fingerprint = D767 DAC9 B3EB CB15 7964 7CC9 9E54 EBE1 826D B190 pub 1024R/95E81DB5 1994-08-07 Key fingerprint = 1A C6 43 10 1B DE 8F 22 CC 4F 6E 50 DF E4 98 51 pub 1024D/F70C5551 1997-11-01 Key fingerprint = 92B2 48A3 D986 61B0 2DA1 AAAC 8B6E 6725 F70C 5551 Regards. Dean Hughes Reminder send 31/5/2018: Date: Thu, 31 May 2018 22:14:35 +0100 Subject: Re: GDPR Erasure Request From: Dean Hughes To: kristian.fiskerstr...@kfwebs.net, k...@eika.no, k...@gnupg.net Hi Kristian I haven't received a response to my request therefore I am copying the email to your other email addresses. You should be aware that under the GDPR data processors and controllers are legally bound to delete personal data within 30 days of receiving a request. Regards. On 29 May 2018 at 13:24,
Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?
On 2/6/19 8:28 PM, Robert J. Hansen wrote: > What we don't have is *consensus* -- not only among ourselves, but in > the larger community. The current discussions we're having (e.g during OpenPGP email summit in brussels in october and lately on FOSDEM last weekend) is eventually not storing UIDs at all on the keyservers, but require the user to do key discovery through WKD, directly on a website or the like. This still allows using keyservers to distribute revocation certificates and updates to subkeys etc, but not as a discovery mechanism. Pool-wise it'd be setting up a separate keyserver network that will gossip with the existing network for a time, with separate pool for the with-uid and without-uid servers, before the full switch is done... The new network would be running on software replacing SKS, using more suited database backend that and multi-threaded implementation. The current disagreement are really with regards to whether this should be "validating keyservers" or not, and how such servers could interact with non-validating ones. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A committee is a group that keeps minutes and loses hours." (Milton Berle) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659
On 1/12/19 8:15 PM, Shengjing Zhu wrote: > I think these requests are quite unusual. > Does anyone know what happens to these two keys? Just to add a comment on this, adding a cache on the load-balancer is really a nice way to slow down hits on the underlying SKS nodes, I keep cache for 10 minutes in nginx, which really makes life more pleasant. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Action is the foundational key to all success" (Pablo Picasso) 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] Withdrawal of Service - keys.flanga.io
On 11/16/18 2:08 AM, Matthew Walster wrote: > Good lord, Kristian, you have to deal with these people on a regular basis? Yes -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) 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] Withdrawal of Service - keys.flanga.io
On 11/16/18 12:23 AM, Fabian A. Santiago wrote: > Wow! I’d love to see that as well. > > I just saw Kristian’s post with his email exchange. It’s a shame the > situation is going down like this. I do hope a proper solution can be > found so I and hopefully others can return to contributing to the > network, should the mode of operation dictate and stay this way. sadly we've had this situation happening several times in the past as well, the GDPR rules aren't actually novel in Europe. There is however a lot of FUD involved in it, and the actual legal action for a keyserver to be shut down has yet to be seen (in a non-voluntary basis). I'm happy to stay up for a while until we see any actual legal challenge to it. In any case, the discussions we've seen lately aren't really about security; nor really about privacy; they are about argumentum ad hominem against the operators of the traditional keyserver network, in favor of alternative communication channels and in particular certificate authorities in the form of "validating keyservers". I don't care much for them for various reasons, but I also don't mind them being a part of the ecosystem (as long as users understand their position). -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] New Article on SKS-Keyservers
On 11/15/18 10:13 PM, Ari Trachtenberg wrote: > Where does it say that the network was meant to be "resilient" to attack? > >> On Nov 15, 2018, at 3:10 PM, Mike wrote: >> >> https://medium.com/@mdrahony/a-single-raspberry-pi-can-take-down-the-entire-sks-keyserver-network-and-its-maintainers-dont-fd829297d75e >> This is the email correspondence involved; https://download.sumptuouscapital.com/tmp/re_new-article.eml.txt -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) 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] Changes to requirements for the HKPS pool
On 7/3/18 11:01 PM, Phil Pennock wrote: > On 2018-07-03 at 12:51 +0200, Kristian Fiskerstrand wrote: >> However, going forwards I'm going to request additional information >> about the server hardware (already requesting info on line capacity for >> SRV pool purposes) for inclusion in HKPS. In particular I'm giving >> preference to clustered setups (in my experience 3 nodes is minimum >> requirement for a most stable setup to allow gossipping), and servers >> that do caching on the reverse proxy. Additionally low-CPU/low-memory >> setups will not be permitted into the HKPS pool. the HKPS pool is now fully served by clustered setups only, hopefully this results in a better user experience for users of the network. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "There is no urge so great as for one man to edit another man's work." (Mark Twain) 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] Clustering
On 08/27/2018 02:43 PM, Fabian A. Santiago wrote: > reallyyou view an sks cluster to be nothing more than multiple > instances running on one server? interestingwould there be any > advantage to using multiple servers / vm's? or would that then be overkill? There would be the usual advantages if there are other outages, e.g during system upgrade, but for the purposes we're talking it just needs to be multiple instances. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Potius sero quam numquam Better late then never ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Clustering (Was: New Keyservers and Dumps)
[Sent from my iPad, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] > On 26 Aug 2018, at 18:44, Alain Wolf wrote: > > Hi > > Am 24.08.2018 um 14:36 wrote Kristian Fiskerstrand: >> On 08/24/2018 11:36 AM, Gabor Kiss wrote: >>> A question: >>> Does an SKS cluster need multiple storage space, >>> or nodes can share the database? >> >> the DB/storage needs to be separate, but it doesn't require multiple VMs >> although I tend to just spin up a new one for each node. >> > > So to clarify, I run a Ubuntu-server 18.04 and assuming I have 100+ GB > of free disk-space: > > 1) I make two additional copies of /var/lib/sks (22GB as of today). > > 2) I give them each a nodename in sksconf, but leave the hostname as > it is. > RIght.. obviously also ports needs to be distinct > 3) I peer all of them with each other in their membership files. > > 4) I somehow convince systemd to run three instances of sks and > sks-recon, each with its own working-dir. > > 5) I tell my Nginx to proxy all three of them. > > 6) I ask around for peers to my two new instances. > > > A) Is that it? Yup.. that is pretty much it. I also recommend a 10 minute cache on the load balancer > > B) Would this be useful? > Very much so.. that should be much more reliable > > Note 1: > I only one single external IPv4-Address, but a delegated IPv6 prefix. So > IPv4 recon will be limited to one of the three instance. That is what I use myself.. one primary doing external gossipping.. each slave only gossip with master.. one reason for this is you don’t want slaves gossiping with others as that reduces time it is available for respons and you always want at least one node responding. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] No status page
On 08/24/2018 06:58 PM, Kristian Fiskerstrand wrote: > On 08/24/2018 06:56 PM, Kiss Gabor (Bitman) wrote: >> Dear Kristian, >> >> Page https://sks-keyservers.net/status/ contains no key servers. > > Yup, I'm on it > Not entirely sure what went wrong, but added some more severs to the bootstrapping process as some of the old ones had dissipated. That said, at least the failsafe mechanism worked so DNS didn't get updated in the time it was down. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Those who don't know history are destined to repeat it." (Edmund Burke) 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] No status page
On 08/24/2018 06:56 PM, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > Page https://sks-keyservers.net/status/ contains no key servers. Yup, I'm on it -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "A government that robs Peter to pay Paul can always depend on the support of Paul." (George Bernard Shaw) 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] New Keyservers and Dumps
On 08/23/2018 11:49 PM, Eric Germann wrote:
> Since I’ve been rolling these myself, I didn’t know a 3 node cluster was best.
>
> As for the 3, if either putting them behind a LB or doing round-robin, how
> would the LB or the client know there was a failure on one and move on in the
> cluster. Most I’ve seen with multiple (??) boxes use two IP’s behind a CNAME
> doing RR DNS.
it hops to another server after timeout or due to 5xx message from
upstream, e.g (nginx):
upstream sks_servers
{
server 192.168.0.55:11372 weight=5;
server 192.168.0.61:11371 weight=10;
server 192.168.0.36:11371 weight=10;
}
Adding a cache on the LB further improves responses, as discussed previously
>
> FWIW, no one has complained, so not too sure it’s an issue, at least for now.
I get all the complains, as they say the pool isn't working.
>
> I do notice I frequently end up with a significant number of them in the hkp
> pool. They do run hkps on LetsEncrypt certs and seem to sync fine, at least
> to GPGSuite.
Most traffic goes to hkps pool these days anyways since that is default
in gnupg.
>
> Do you have a best-practices deployment doc, because it’s pretty much been
> trial by fire. For example, killing the daemon gives you about a 50% chance
> of blowing up the db. For the longest time I rebuilt, not knowing an “sks
> cleandb” would fix it 99% of the time.
Very few scenarios where you would kill the daemon though, but the
archive of the ML has many discussions, you also have
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering giving
good pointers.
>
> Docs seem a bit thin. I was trying to up pool count since a lot seem to have
> gone by the wayside, adding some geo-diversity and running one in Africa.
> Not sure if there are any others down there.
>
> It’s an interesting experiment. If it’s an issue let me know and I will shut
> some/it down.
>
Its not an issue, but in practice it doesn't necessarily add much value
either, more clustered setups are more important for the ecosystem than
even more individual servers.
> EKG
>
>
>> On Aug 23, 2018, at 9:49 AM, Kristian Fiskerstrand
>> wrote:
>>
>> On 08/20/2018 03:26 PM, Eric Germann wrote:
>>> I’ve reworked the keyserver fleet we’d previously deployed and made a blog
>>> post [1] about it.
>>
>> Are the servers clustered in any way? In my experience each site needs
>> at least 3 nodes to ensure proper operation (mainly if A and B are
>> gossipping C can still respond to requests, depending on the amount of
>> traffic / speed of the node to return more is better)
>>
>> So clustered setup is more important than large number of individual
>> servers, as there is no retry functionality in dirmngr.
>>
>> I'm still looking for more clustered setups to include into hkps pool,
>> in particular since noticing an interesting feature if only one server
>> is included, which disables pool behavior in dirmngr and results in TLS
>> error / generic error due to CA pem not being loaded...
>>
>> --
>>
>> Kristian Fiskerstrand
>> Blog: https://blog.sumptuouscapital.com
>> Twitter: @krifisk
>>
>> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
>> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
>>
>> "We all die. The goal isn't to live forever, the goal is to create
>> something that will."
>> (Chuck Palahniuk)
>>
>
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"The laws of Australia prevail in Australia, I can assure you of that.
The laws of mathematics are very commendable, but the only laws that
applies in Australia is the law of Australia."
(Malcolm Turnbull, Prime Minister of Australia).
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] Clustering (Was: New Keyservers and Dumps)
On 08/24/2018 11:36 AM, Gabor Kiss wrote: > A question: > Does an SKS cluster need multiple storage space, > or nodes can share the database? the DB/storage needs to be separate, but it doesn't require multiple VMs although I tend to just spin up a new one for each node. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "My father used to say: ‘Don’t raise your voice, improve your argument.’" (Desmond Tutu) 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] New Keyservers and Dumps
On 08/20/2018 03:26 PM, Eric Germann wrote: > I’ve reworked the keyserver fleet we’d previously deployed and made a blog > post [1] about it. Are the servers clustered in any way? In my experience each site needs at least 3 nodes to ensure proper operation (mainly if A and B are gossipping C can still respond to requests, depending on the amount of traffic / speed of the node to return more is better) So clustered setup is more important than large number of individual servers, as there is no retry functionality in dirmngr. I'm still looking for more clustered setups to include into hkps pool, in particular since noticing an interesting feature if only one server is included, which disables pool behavior in dirmngr and results in TLS error / generic error due to CA pem not being loaded... -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) 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] Changes to requirements for the HKPS pool
On 07/03/2018 12:51 PM, Kristian Fiskerstrand wrote: > Although the requirements to get included in the HKPS pool have so far > been a bit subjective and changing over time as I've gotten more > experience (and balancing out the requirements for the pool - it is not > the point for me that every server that requests it gets included). > > However, going forwards I'm going to request additional information > about the server hardware (already requesting info on line capacity for > SRV pool purposes) for inclusion in HKPS. In particular I'm giving > preference to clustered setups (in my experience 3 nodes is minimum > requirement for a most stable setup to allow gossipping), and servers > that do caching on the reverse proxy. Additionally low-CPU/low-memory > setups will not be permitted into the HKPS pool. > Following up on this, those that have submitted CSRs and not gotten signed cert back are asked to re-send it with the additional info provided above (for clarity; as metadata not in the csr). -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Those who don't know history are destined to repeat it." (Edmund Burke) signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Changes to requirements for the HKPS pool
Although the requirements to get included in the HKPS pool have so far been a bit subjective and changing over time as I've gotten more experience (and balancing out the requirements for the pool - it is not the point for me that every server that requests it gets included). However, going forwards I'm going to request additional information about the server hardware (already requesting info on line capacity for SRV pool purposes) for inclusion in HKPS. In particular I'm giving preference to clustered setups (in my experience 3 nodes is minimum requirement for a most stable setup to allow gossipping), and servers that do caching on the reverse proxy. Additionally low-CPU/low-memory setups will not be permitted into the HKPS pool. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you choose to sail upon the seas of banking, build your bank as you would your boat, with the strength to sail safely through any storm." (Jacob Safra (1891–1963)) 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] Keyserver Network Down?
On 06/19/2018 11:17 PM, Kristian Fiskerstrand wrote: > On 06/19/2018 11:09 PM, Kristian Fiskerstrand wrote: >> On 06/19/2018 10:53 PM, Matthew Walster wrote: >>> The keyserver status page seems broken also: >>> https://sks-keyservers.net/status/ >> >> This was an intermittent failure, should be back up now.. Needed to >> shift around some primaries to bootstrap the crawler. >> > > That said, looks to be very high activity towards my cluster atm, which > was why it timed out on my own server initially during last search, > seems more than 37k hosts requesting keyblocks just from my server > today, so might have to spin up a couple more nodes in the cluster. > Seems to be a very high request for mongodb release key, so forcing caching on the front-end helps relaxing SKS quite a bit, see https://www.nginx.com/blog/nginx-caching-guide/ https://www.digitalocean.com/community/tutorials/understanding-nginx-http-proxying-load-balancing-buffering-and-caching some hints proxy_cache backcache; proxy_ignore_headers Cache-Control "Expires"; proxy_cache_valid any 30m; -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Fabricando fit faber Practice makes perfect 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] Keyserver Network Down?
On 06/19/2018 11:09 PM, Kristian Fiskerstrand wrote: > On 06/19/2018 10:53 PM, Matthew Walster wrote: >> The keyserver status page seems broken also: >> https://sks-keyservers.net/status/ > > This was an intermittent failure, should be back up now.. Needed to > shift around some primaries to bootstrap the crawler. > That said, looks to be very high activity towards my cluster atm, which was why it timed out on my own server initially during last search, seems more than 37k hosts requesting keyblocks just from my server today, so might have to spin up a couple more nodes in the cluster. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you don't drive your business, you will be driven out of business" (B. C. Forbes) 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] Keyserver Network Down?
On 06/19/2018 10:53 PM, Matthew Walster wrote: > The keyserver status page seems broken also: > https://sks-keyservers.net/status/ This was an intermittent failure, should be back up now.. Needed to shift around some primaries to bootstrap the crawler. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aurum est Potestas Gold is power 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] Keyservers and GDPR
On 05/23/2018 11:27 AM, ilf wrote: > tl;dr: Keep calm and keep running keyservers. > > Vincent Breitmoser: >> (cross-posting on all the cool pgp lists) > > (I wonder, if this really needs to be an all the four lists. I think > sks-devel@ might be the most appropriate. Having said that, I'm only > replying to gnupg-devel@ because I'm not subscribed to sks-devel@. Feel > free to relay my message.) As I think this has a valuable viewpoint I'm posting it to sks-devel. And yes, this is mostly in line with my own thinking, I don't expect the need for radical changes unless we see actual attempts to go after the infrastructure. > >> My personal conclusion is that keyservers that support user id packets >> are, quite simply, incompatible with GDPR law. > > There is a ton of FUD about the GDPR out there right now. Most of it > frivolous. (Actually, a lot of it is deliberate fearmongering by people > who happen to sell legal advice on the GDPR.) > > First of all, the GDPR is not completely new. All EU member states > already have data protection laws, some - like Germany - already very > strong ones. The concepts (PII, responsibilities, technological and > organisational measures, information and documentation obligations) have > already been in place with the old Data Protection Directive from 1995, > which the GDPR is updating. I admit that the GDPR can be read and > interpreted in a fatalist way. But most people leaning that way seem to > not have read the older laws. > > Laws are not set in stone. Laws include leeways, deliberate or > unintended. Laws do not depend on their interpretation by laypeople. > There is a huge dedicated system for its interpretation, conflict > resolve, judgement and enforcement. > > In the case of the GDPR, the very first step of that system are National > Data Protection Authorities (DPA). They have the power - and the > responsibility - to investigate possible violations of the GDPR. They > have been understaffed for years, in many countries dangerously so. They > are getting a lot more powers and responsibilities with the GDPR, but > their resources are growing way slower than their tasks. They are simply > understaffed and overworked. So from all the possible GDPR violations > they will be notified about, they will work off the biggest and most > obvious ones first. Their focus will be on the Facebooks - and not on > small nerd projects or personal websites. They have the power to say "we > don't care about this weird thing called keyserver" - and the probably > will. > > Now even if someone found data protection law infringements with a > keyserver, filed a specific and well-worded legal complaint with a DPA, > and a DPA found the resources to look into it, and the DPA found some > violation of the GDPR (four big IFs!) - the DPAs will not go around and > issue sanctions and fine people. First of all, their job is not to > generate revenues by fines. Their job is to enforce data protection law. > If a DPA did find an issue with a keyserver - or the very concept - they > would reach out and talk to the people running the servers. They would > hear their perspective, learn more about the very concept - and try to > work out a viable solution to provide the service without possible data > protection infringements. This is their job and their goal. > > The most feared sanction of some undefined GDPR violation is a fine. As > I layed out, DPAs don't want to issue fines, they want to stop privacy > violations. And they will not blindly issue a fine without talking to > you first. That being said, they obviously do have the power to issue > fines. After due process. However, this power is also not new, it has > also existed in many countries. And DPAs don't run around and fine > people left and right (you would have heard about that), they exercise > their power in a balanced way. And fines are always in relation to the > economic and personal circumstances of the - then guilty and obstinate - > data protection violators. I guess most keyservers are run by > non-profit individuals or institutions. Even if a company runs a > keyserver, it doesn't make money with that service. Therefore, I think > the chance of *any* fine is negligible - and the chance of an > unreasonably high fine is almost zero. And if it ever came to this, the > community and public alarmed by public outcry would probably donate more > than the fine issued. > > To sum up: Keep calm and keep running keyservers. You'll be fine. > > More elaboration in German: > https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/ > > > Disclaimer: IANAL. Thi
Re: [Sks-devel] Strange case
On 05/20/2018 10:14 PM, Kristian Fiskerstrand wrote: > On 05/20/2018 01:31 AM, Webmaster IspFontela wrote: >> >> Now we just need to find out why the server a.0.keysnode.ispfontela.es >> on the list https://sks-keyservers.net/status/ has disappeared, I guess >> that will be a matter of time. > > This server I explicitly added to blacklist for misbehaving with > redirect for 11371 to 443 > fwiw, I didn't add it to repo initially, but it is part of https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=commitdiff;h=0a3962f591d2206aebd739bd4bec90809cc93822;hp=debbac15b210f4b9ced2235a8d3f0da1d3c4f144 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Don't be afraid to go out on a limb. That's where the fruit is." (H. Jackson Browne) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Strange case
On 05/20/2018 01:31 AM, Webmaster IspFontela wrote: > > Now we just need to find out why the server a.0.keysnode.ispfontela.es > on the list https://sks-keyservers.net/status/ has disappeared, I guess > that will be a matter of time. This server I explicitly added to blacklist for misbehaving with redirect for 11371 to 443 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Divide et impera Divide and govern ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Inconsistency on vindex page with machine-readable flag set or unset?
On 05/09/2018 09:15 PM, Phil Pennock wrote: > in > match exptime_delta with > | None -> (None,None) > | Some _ -> (ctime,exptime_delta) > > I suspect that the `None` line there should be yielding (ctime,None) > instead of (None,None); in other words, the four lines above should just > become: > > in > (ctime,exptime_delta) > > The mRindex.ml code is the only place that get_key_exptimes is called, > and looks to handle the Some unpacking safely already, so it should be > safe to change, but I'm not set up to play around with this right now to > confirm and see if there are negative side-effects. https://bitbucket.org/skskeyserver/sks-keyserver/commits/f187022f7583c56216ca5871c56b0639ad837481 springs to mind. The creation time of the self-signature is needed to use the latest self-sig. But it is so long ago I don't recall if we checked if it was used everywhere. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Divide et impera Divide and govern 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] Implications of GDPR
On 04/30/2018 01:59 PM, Andrew Gallagher wrote: > Certificate validation may also be an issue, because many HTTPS pool > members only have the pool SSL certificate - which won't validate in the > normal manner when bypassing the pool round-robin. The certs includes CN and SANs for the keyserver, so it could still be used in this scenario, actually. The SNI setups I've seen with deviating handling use e.g letsencrypt cert when doing direct keyserver request, but that would still validate. But you'd potentially also have issues with keydumps as well as split pools serving different keyblocks depending on which server you hit - so I believe the underlying question is more complex than just throwing https on it, although it is certainly possible to do so. Immediately it sounds like just increasing the overhead without much value added though (the data is public anyways), but the whole GDPR is a mess to begin with. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Expect the best. Prepare for the worst. Capitalize on what comes." (Zig Ziglar) 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] Cease of operation: *.gnupg.pub
On 04/24/2018 10:57 AM, Franck Nijhof wrote: > My initial message was not about the hosting, but being able to > manipulate the system with ease, Somehow, that severe and alarming > message is now overshadowed by a discussion on Open Source > platforms. It would be helpful if you described the threat model you're worried about and actual impacts. fwiw, as far as I can see your servers were never included in hkps nor tor ports either which reduces some privacy angles. If you're worried about info leak there are easier ways for an attacker to impact traffic though, but the original report reads too much like a rant and has insufficient info to comment much. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) 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] Cease of operation: *.gnupg.pub
On 04/24/2018 10:20 AM, Valentin Brandl wrote: > > > Am 2018 4 23 20:00:01 UTC schrieb Franck Nijhof : >> I am not sure if the little Git server thingy on that Sumptuous >> Capital domain qualifies. Bitbucket is a fine service by Atlassian, >> but let's be honest here, if you are serious about Open Source, >> GitHub is the place to be. Open Source requires, issue management, >> pull requests and above all: contributors! Unfortunately, the >> latter are mostly found on GitHub. >> >> Nevertheless, thank you for your response Travis, that is very >> much appreciated. > > While I agree with you that hosting the code on a smaller platform > like bitbucket might keep some people from contributing, I'm actually > glad there are projects that choose not to host their code on > GitHub. You can actually use GitHub as authentication provider for > Bitbucket so you are not required to create a new account to > contribute to SKS. > I find the claim of relying on a proprietary service "if you are serious about Open Source" somewhat more interesting. In any case, github has a tendency of destroying proper commit messages etc for the pull requests. That said, nothing stops a contributor from using github to host their repo then doing a proper git pull request (man git-request-pull) or just a git-format-patch. This was described in more detail in https://www.wired.com/2012/05/torvalds-github/ and comments starting with at least https://github.com/torvalds/linux/pull/17#issuecomment-5654674 -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "In politics stupidity is not a handicap." (Napoleon Bonaparte) 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] disk space
[Sent from my iPad, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] > On 22 Apr 2018, at 12:18, Shengjing Zhu wrote: > > Hi Paul, > >> On Mon, Jan 22, 2018 at 07:01:19PM +0100, Paul Fontela wrote: >> Hi All, >> >> Checked, I went from 118G in /var/lib/sks/KDB/ to 3GB after adding the >> DB_CONFIG file inside the KDB folder. >> More than 11,000 files have been deleted log.0xx. >> > > Just want to confirm your KDB directory is 3GB? I setup a new server > today, and I see it's 20GB. Possible difference is fastbuild vs normalbuild.. for fastbuild only references since dump is kept so if dump is recent enough not too many changes. > > BR, > Shengjing Zhu > ___ > 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 apocalypse mitigation
[I previously responded to a specific message not related to this thread but none the less... ] On 03/23/2018 03:02 PM, Daniel Kahn Gillmor wrote: > On Fri 2018-03-23 11:10:49 +, Andrew Gallagher wrote: >> Updating the sets on each side is outside the scope of the recon >> algorithm, and in SKS it proceeds by a sequence of client pull requests >> to the remote server. This is important, because it opens a way to >> implement object blacklists in a minimally-disruptive manner. > > as both an sks server operator, and as a user of the pool, i do not want > sks server operators to be in the position of managing a blacklist of > specific data. I would definitely agree with this > >> The trick is to ensure that all the servers in the pool agree (to a >> reasonable level) on the blacklist. This could be as simple as a file >> hosted at a well known URL that each pool server downloads on a >> schedule. The problem then becomes a procedural one - who hosts this, >> who decides what goes in it, and what are the criteria? > > This is a really sticky question, and i don't believe we have a global > consensus on how this should be done. I don't think this approach is > feasible. > >> Another effective method that does not require an ongoing management >> process would be to blacklist all image IDs - this would also have many >> other benefits (I say this as someone who once foolishly added an >> enormous image to his key). This would cause a cliff edge in the number >> of objects and, unless carefully choreographed, could result in a mass >> failure of recon. >> >> One way to prevent this would be to add the blacklist of images in the >> code itself during a version bump, but only enable the filter at some >> timestamp well in the future - then a few days before the deadline, >> increase the version criterion for the pool. That way, all pool members >> will move in lockstep and recon interruptions should be temporary and >> limited to clock skew. > > I have no problems with blacklisting User Attribute packets from sks, > and i like Andrew's suggestion of an implementation roll-out, followed > by a "switch on" date for the filter. I support this proposal. > I agree with this as well, UAT generally have very limited value, so if we introduce a filter to skip all UATs I'm all fine with making that a requirement across severs in sks-keyservers.net pools. That isn't something that restricts servers overall, but anyhow... > I've had no luck getting new filters added to sks in the past [0], so > i'd appreciate if someone who *does* have the skills/time/commit access > could propose a patch for this. I'd be happy to test it. and here comes at least one of the issues, we're talking about a filter that responds to a specific alteration; mainly we need to specify a specific filter for a specific version and move from there, which can be relatively easy given sufficient time. > > --dkg > > [0] see for example > https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20/trim-local-certifications-from-any-handled > > > > ___ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "There is no urge so great as for one man to edit another man's work." (Mark Twain) 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] TLS 1.3 and HKPS pool
On 03/19/2018 10:40 PM, Hendrik Visage wrote: >> Now.. if anyone were to actually disable everything but 1.3, that'd be >> exclusion worthy from the pool, but lets do this manually if so. > > I’ve not seen and TLS1.2 security issues yet (but then I might’ve missed it > in the deluge of meltdown/spectre/memcached) so I don’t see the need/reason > to disable TLS1.2 I was referring to server operators here, not clients, if that wasn't clear :) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Don't be afraid to go out on a limb. That's where the fruit is." (H. Jackson Browne) 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] TLS 1.3 and HKPS pool
On 03/19/2018 10:08 PM, Phil Pennock wrote: > Do we care? I'm tempted to say no.. if there is a breakage that needs to be fixed anyhow, and for most users on LTS branches of distros it will take a while for the libraries that use tls 1.3 to begin with will be distributed. If a client experience issues on it they can disable it, although it might be worthwhile to file a RFE for gnupg's dirmngr if we encounter such issues for it to add a tls version flag; doesn't it make more sense for the client to specify version than to try to control it server-side (and monitoring it) Now.. if anyone were to actually disable everything but 1.3, that'd be exclusion worthy from the pool, but lets do this manually if so. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Veni, vidi, vacatum I came , I saw, I left 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] Machine readable version of SKS key server stats
On 02/15/2018 09:46 AM, Kristian Fiskerstrand wrote: > On 02/15/2018 05:51 AM, Eric Germann wrote: >> Good evening all, >> >> Are there any docs anywhere regarding the HTTP request that can be made on >> port 11371? >> >> Specifically, wondering if /pks/lookup?op=stats can return a machine >> readable format (JSON, XML, etc) for server stats, etc. >> >> Thanks for any pointers. >> >> EKG > > > Look at json format for &options=mr on a hockeypuck server > i.e SKS does not have such a format, but the crawler supports it based on the template discussed with hockeypuck previously so it can be used in general for pools etc. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) 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] Machine readable version of SKS key server stats
On 02/15/2018 05:51 AM, Eric Germann wrote: > Good evening all, > > Are there any docs anywhere regarding the HTTP request that can be made on > port 11371? > > Specifically, wondering if /pks/lookup?op=stats can return a machine readable > format (JSON, XML, etc) for server stats, etc. > > Thanks for any pointers. > > EKG Look at json format for &options=mr on a hockeypuck server -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) 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] SKS Statistcs
On February 3, 2018 11:31:06 AM GMT+01:00, Valentin Sundermann wrote: >Hey, > >> Is there method to get sks server statistics (key count etc..) other >> then http request? I want to graph statistics using Cacti, so i need >get >> this info quite often. > >As far as I know there isn't any way to get machine readable statistics >out of an SKS instance other than requesting the stats page and parsing >these information. > >If you're interested in already parsed data, you can have a look at >https://apps.vsund.de/skstat/status. I originally wrote this to make >fancy graphs and statistics but never finished. It's still collecting >data and providing them as JSON (useful for monitoring or statistics). > >If anyone reading this plans to depend on the interfaces (such as the >CSV download or JSON), please leave me a message. I might change the >interfaces when I pick up the work on this app. And also leave me a >message if you have feedback, criticism or wishes for this app. > >Thanks & best regards, >Valentin You can also look at the munin implementation at https://git.sumptuouscapital.com/?p=munin-sks.git;a=summary Keep in mind stats by default are updated once a day and by convention hourly through system signals -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] disk space
On 01/20/2018 04:07 PM, Michael Jones wrote: > Time for an upgrade of disk space on my nodes, if anyone is interested > in the usage over time, here's a 6month graph; > I'd expect this isn't without set_flags DB_LOG_AUTOREMOVE in DB_CONFIG, i.e you can purge some archived DB files using db*_archive? -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nil satis nisi optimum Nothing but the best is good enough 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] Krisitian?
On January 17, 2018 3:58:37 PM GMT+01:00, Eric Germann wrote: >Good morning, > >Does anyone know if Kristian still maintains his site and the signing >service for CSR’s for four sites? Also, updating the Tor and bandwidth >data for each of the respective servers. > >I’ve sent several emails to several addresses listed in the key and >heard nothing back nor seen and bounces. > >If you’re out there you can reach me via the emails I sent or ekgermann >at gmail if it’s a bounce/blacklist issue. If anyone knows a different >address, please let me know back privately. > >Thanks > >EKG I've gotten the emails :) still doing due dilligence for csr decision of whether to sign or not, server is a bit nee and I prefer strongly connected (wot strongset) operators -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Fwd: Re: Fwd: Re: Unde(r)served HKPS [was: Underserved areas?]
On 01/14/2018 07:43 PM, Heiko Richter wrote: > I bet the private key of "Kristian-CA" is on a system that is > permanently connected to the internet and as soon as that key gets lost > *all* GnuPG installations can't be trusted to do secure HKPS because > some brainbug who didn't know the first thing about security hardcoded > that certificate into the software. To make sure this isn't un-challenged in the archives, the secret key never touches an online system, all operations are done on airgapped setup. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Qui audet vincit Who dares wins 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] Unde(r)served HKPS [was: Underserved areas?]
On 01/14/2018 08:46 PM, Kristian Fiskerstrand wrote: > From a privacy perspective, then yes, using HKPS transport is better, > but it doesn't improve anything if malicious servers are included in > some way that records information anyways, so having all servers > included reduces privacy, it doesn't improve anything, as long as the > pool itself is operational. I should add here that same goes for the Tor OnionBalance service. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you are successful, you may win false friends and true enemies. Succeed anyway." (Mother Teresa) 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] Unde(r)served HKPS [was: Underserved areas?]
On 01/14/2018 08:36 PM, Alain Wolf wrote: > Unfortunately the problem of 95% of the server pool not supporting > HKPS out of the box remains unresolved. For now. > > My opinion is still the same: Unencrypted HKP should be the exception > and HKPS the rule. The majority of the pool servers need to be in the > HKPS pool and HKP then might be slowly phased out and deprecated. From a security perspective that isn't necessary. OpenPGP is utilizing object based security, whereby the packets are signed. So HKP has no security implication. From a privacy perspective, then yes, using HKPS transport is better, but it doesn't improve anything if malicious servers are included in some way that records information anyways, so having all servers included reduces privacy, it doesn't improve anything, as long as the pool itself is operational. And fwiw, none of the geographical sub-pools are doing anything re HKPS, that is a single global pool. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Timendi causa est nescire The cause of fear is ignorance 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] Unde(r)served HKPS [was: Underserved areas?]
On 01/14/2018 01:04 PM, Heiko Richter wrote: > The fact that your GPG client shows a secure connection is > either due to a faulty/incomplete validation algorithm that doesn't > check the ca signature of the servers cert or because "Kristian-CA" is > hardcoded into GnuPG. I don't know which one it is and don't really care > because both situations would be relics of 90s-incompetence that > compromise security and should have been removed from gnupg years ago. Quite the contrary, this is the correct behavior from a security perspective. And yes, the CA is included for the pool specifically. Using HKPS from web browser is less of an issue as that is wrong use of keyservers in nine out of ten situations as a local client is anyways needed to properly validate the packet information provided in the OpenPGP keyblock. That said I'm a bit surprised about this discussion, nobody is required to use a single pool of keyservers. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Amantes sunt amentes Lovers are lunatics 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] Unde(r)served HKPS [was: Underserved areas?]
On January 11, 2018 11:28:08 PM GMT+01:00, Moritz Wirth wrote: >I requested a certificate a few days ago, however only well known >keyservers receive a cert for HKPS (which is reasonable because the >certificates are valid for a year and there is no reliable way for >certificate revocation). > >Another idea around the mitm problem - the client retrieves the current >list of servers in the pool, looks up their hostnames from the >sks-keyservers.net website (or somewhere else) and connects to the >server using the hostname, not the pool adress - Therefore, you would >not need additional names in the certificates and it would be easy for >operators to obtain own certificates. Malicious servers can be avoided >easily by kicking them out of the pool dns and the certificate itself >is >useless as it only secures the own hostname. > >Best regards, > >Moritz > >Am 11.01.18 um 22:30 schrieb Alain Wolf: >> >> On 11.01.2018 18:16, Alain Wolf wrote: >>> Opinions, ideas anyone? >>> >> Maybe something along the line of ... >> >> 1) Server operator puts his PGP fingerprint in the servers contact >> information (as we do today but would need to be mandatory HKPS). >> >> 2) Server operator creates server private key and CSR. >> >> 3) Server operator stores CSR on the server in something like >> ./well_known/hkps/0x27a69fc9a1744242.csr >> >> 3) Server operator signs the CSR with his PGP key and puts the >signature >> in ./well_known/hkps/0x27a69fc9a1744242.csr.asc >> >> 4) Kristian's hourly checking script does the usual tests but >> additionally tries to fetch the CSR from its .well-known location. >> Checks if the PGP signature of the CSR was done with the key who's >> fingerprint is in the servers contact information. >> >> 5) The script signs the CSR with the CA key and sends the signed cert >to >> the server operator in a PGP encrypted mail. >> >> 6) Server operator installs the signed cert on his server. >> >> 7) The checking script could do some HKPS checks. Valid certificate? >Not >> expired? Deprecated ciphers? Perfect forward-secrecy? etc. >> If everything checks-out server is added to hkps.pool (This might >> already be the case today) >> >> Cert expiry could be 3 months, checking script removes any server >from >> the pool who's cert expires in the next 24 or 48 hours. Cert should >not >> be valid longer then the operators PGP key. >> >> For certificates renewals, the process could be the same, a new >> certificate is issued as soon as the checking script finds a new CSR >(or >> the same CSR but a new PGP signature along with it). >> >> Server cert revocations could be requested manually by asking the CA >> operator or automatically by placing a PGP signed >> 0x27a69fc9a1744242.revoke.asc file in to the .well-known directory. >> >> Revocation or expiry of the servers operators PGP key, should lead >> automatically to the revocation of the server cert and removal of the >> server from the pool. >> >> After a while this could be made mandatory. So 100% of the sks-pool >> servers are also in the hkps.pool >> >> Creation of server keys, CSR and PGP signing could be automated (or >> partly automated because of the PGP signing) by scripts distributed >with >> the SKS software package. >> >> I don't think I am really qualified for designing new security >> protocols, but the idea doesn't go out of my head. Sorry for the long >post. >> >> Regards >> >> Alain >> >> >> >> ___ >> Sks-devel mailing list >> Sks-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/sks-devel A misissued cert could still be used if attacker is persistent enough. Either through dns poision or other attack vectors. And yes, I only issue certs to servers I recognize to have been in the pool for a while and operator should be in the openpgp wot strong-set. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] sks-keyservers.net / status / keyserver.ispfontela.es
On 12/18/2017 10:00 PM, Webmaster IspFontela wrote: > > The only change I've made has been to add 2 new peers > > What has happened? Seems the stats page is a non-standard one so it just fails scraping the data. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nulla regula sine exceptione No rule without exception 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] "funny sks :-)" eh?
On 12/17/2017 09:36 AM, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > Is it you who are pushing the envelope? :-) > Do you want to know the limits of key servers? > > Or someone else buggered you around? > In this case we can see another example of how easy to deprave > this infrastructure. That is actually a few years old, using the regular [trollwot] > > http://keys.niif.hu/pks/lookup?op=vindex&search=0x0B7F8B60E3EDFAE3 > (scroll down) > References: [trollwot] https://raw.githubusercontent.com/micahflee/trollwot/master/trollwot.pdf -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw 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] Emergency Maintenance: sks.mirror.square-r00t.net
On 12/10/2017 11:20 PM, brent s. wrote: > On 12/10/2017 05:15 PM, Kristian Fiskerstrand wrote: >> Good that things are restored, but to try to debug this more generally, >> can you confirm you used fastbuild rather than a full build originally? > > full build has always been used, both in the original turnup and in this > new turnup. > >> In that case the offsets referenced can have been changed during this >> process, and the behavior being within the expected behavior. >> > > N/A In that case I'm surprised the expansion of disk store didn't work, which isn't a big problem for the general keyserver in the global gossiping network, but it _could_ cause issues for stand-alone servers. So definitely not good. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Success is getting what you want. Happiness is wanting what you get" (Dale Carnegie) 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] Emergency Maintenance: sks.mirror.square-r00t.net
On 12/10/2017 11:09 PM, brent s. wrote: > On 12/10/2017 12:50 PM, brent s. wrote: > >>> has anyone seen that "Fatal error: exception Keydb.Unsafe.No_db" before >>> (esp. after growing a filesystem)? I don't seem to have any other >>> inconsistent data on the filesystem from what i can tell >>> >> >> Decided to just rebuild the DB from scratch. Will be down for a bit. >> Sorry, peers et. al.! > > > services have been restored and from a fresh upstream dump, at that. > recon's running. thanks all. Good that things are restored, but to try to debug this more generally, can you confirm you used fastbuild rather than a full build originally? In that case the offsets referenced can have been changed during this process, and the behavior being within the expected behavior. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "History doesn't repeat itself, but it does rhyme." (Mark Twain) 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] Cleanup SKS Logs
On 12/08/2017 06:22 PM, Fabian A. Santiago wrote: > can you add DB_LOG_AUTOREMOVE to an existing setup without affecting > anything adversely or having to do anything else other than a > restart? As implied by the other posts, I can confirm that there is indeed no issue to change for existing data stores. Some changes to config requires recreating the BDB environment, which can be done using the UPGRADING procedures, but you'd mostly need to do that if experiencing issues / it not taking. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Uxor formosa et vinum sunt dulcia venena Beautiful women and wine are sweet venom 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] mailsync usage
On 12/08/2017 08:34 PM, Fabian A. Santiago wrote: > is there any reason to enable mailsync functionality? does anyone out there > still use it? tl,dr; No -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Uxor formosa et vinum sunt dulcia venena Beautiful women and wine are sweet venom 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] Cleanup SKS Logs
On 12/06/2017 08:10 PM, Moritz Wirth wrote: > Can we delete the logfiles in the KDB/ directory (log.x) - are there > other ways to save some space? the sample DB_CONFIG includes set_flags DB_LOG_AUTOREMOVE that should solve this for you automatically. But you have some info on manual procedure in UPGRADING file, specifically look for db5.3_archive or similar for your distribution (there are some differences in naming conventions etc for multiple versions) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Ubi mel ibi apes Where there's honey, there are bees 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] Missing peers on status page
On 10/04/2017 03:46 PM, Alain Wolf wrote: > Really strange, but searchy.nl now completely vanished from the status > page list, from the list of my peers on [1] and if I open the url > directly it shows another server [2]. > > > [1] https://sks-keyservers.net/status/ks-status.php?server=pgpkeys.urown.net > [2] https://cloud.urown.net/s/fuJPFG9JY53Voaj I'm a bit curious what happened here myself, but don't have time for proper debugging. I flushed some caches and started an update run that should complete within the next few minutes, though, hopefully that sorts it. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Nil desperandum Never give up 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] Missing peers on status page
On 10/04/2017 02:52 PM, Frank de Bot wrote: > Wouldn't this cause to also route a search with 'stats' only to the > primary server? ;-) $arg_op in this case actually means "?op" as key, its not an arbitrary key in the querystring :) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aquila non capit muscas The eagle does not hunt flies 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] Missing peers on status page
On 10/04/2017 02:32 PM, Frank de Bot wrote:
> It seems ausing some confusion, so I've adjusted the loadbalancer to
> route the pks/lookup?op=stats to the 'outward facing' sks instance.
> (Because of the only difference with queries was the query string, it
> was quite some trying and failing with rewrite in apache)
Don't know the syntax in apache, but for others trying to do the same
using nginx it is along the lines of
map $arg_op $upstream_server {
"stats" sks_servers_primary;
default sks_servers;
}
where sks_servers and sks_server_primary are defined as upstream
--
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
"At 18 our convictions are hills from which we look; At 45 they are
caves in which we hide."
(F. Scott Fitzgerald)
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] Missing peers on status page
On 10/04/2017 06:02 AM, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > I've noticed that page > https://sks-keyservers.net/status/ks-status.php?server=keyserver.searchy.nl > does not list any peers. > However according to > http://keyserver.searchy.nl:11371/pks/lookup?op=stats > server has 13+2 gossip partners. > > I wonder if the two pure IP addresses make your supervisor > software confused? :-) > Only IP addresses are [listed], and IPs are filtered in the front (in particular internal ones are excluded altogether). It might be a misconfigured cluster where the stats requests hits a secondary node instead of the primary. Unless it is the starting point for a mesh walk it doesn't really matter, though, and the peer display is only informational. References: [listed] https://download.sumptuouscapital.com/tmp/Screenshot_2017-10-04-08-52-45.png -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "We all die. The goal isn't to live forever, the goal is to create something that will." (Chuck Palahniuk) 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] Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6]
On 09/07/2017 12:16 AM, Daniel Kahn Gillmor wrote: > We only lose 3 members from the hkps pool, and 2 members from the > onionbalance, so i'd recommend making it a minimum there too. Just for clarification, main pool will always be a superset of both HKPS and onionbalance, so any increase in requirement in main pool will automatically affect the subpools. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aquila non capit muscas The eagle does not hunt flies 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] Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6]
On 09/07/2017 12:16 AM, Daniel Kahn Gillmor wrote: 4 > We will (temporarily) go from 116 members of the main pool to 85 -- a > loss of about 25%. But we also provide an incentive for those members > to upgrade to 1.1.6, so i expect we'll make some of that back. > > We only lose 3 members from the hkps pool, and 2 members from the > onionbalance, so i'd recommend making it a minimum there too. > Yup, already executed, and with a few renewals of HKPS executed for 1.1.6 servers we're net -1 on HKPS. > > I recommend requiring at least SKS 1.1.6 for membership in all the > pools. already done -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "I disapprove of what you say, but I will defend to the death your right to say it." Evelyn Beatrice Hall (summarizing Voltaire signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] sks-keyservers.net: increased minimum requirement to SKS 1.1.6
Dear List, SKS 1.1.6 was released more than a year ago ( August 2016), so I've just bumped the minimum requirement for the main pool of sks-keyservers.net to it, this allows for Ed25519 and Curve25519 support. See also discussion in gnupg-devel at https://lists.gnupg.org/pipermail/gnupg-devel/2017-September/033063.html -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Vincit qui se vincit He who conquers conquers self 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] Internal SKS in .de, Hamburg looking for peers.
On 08/23/2017 12:25 PM, Tobias Schultz wrote: > Since it shall be an internal service for the mailtgateway we only > accept 11370 traffic. > > Frontend is not reachable from the outside. I hope thats okay for you. > FYI; You would have to open up the advertised hkp port (by default 11371) to your peers at least to allow exchange of some public keyblocks. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "I disapprove of what you say, but I will defend to the death your right to say it." Evelyn Beatrice Hall (summarizing Voltaire 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] hg workflow pointers
On 08/10/2017 03:24 PM, Daniel Kahn Gillmor wrote: > I'm > not asking this question to push you or other hg-preferring developers > out of sks, Jason, and would welcome suggestions for how to have a > bigger tent. sks suffers from a lack of active development, and we need > more eyes on it if the OpenPGP community is going to continue to rely on > keyservers. Well, the level of activity reflects to some extent the stability of the affected standards.. new features such as elliptic curves of various kinds have been in released stable versions of SKS before other implementations (naturally, since the complexity of searching and storing is lower than using it). The issues lately causing need for fixes is silly breakages in minor version bumps in ocaml (I don't care that the developers say 4.04 to 4.05 is a major bump, its not, they need to get their versioning right and stop doing silly API breaking stuff) As for attracting new people; Its a specialized interest, very few have a handle on OpenPGP overall, and uses vary greatly, e.g some focus more on privacy than security, at which point keyserver might not be the right thing for them to begin with due to social graph leak. ... noting of which is a result of the choie of VCS impacting this to a great extent. If anything we'd need to rewrite the full codebase in C for such an argument to be made. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw 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] hg workflow pointers
On 08/11/2017 06:50 AM, Daniel Kahn Gillmor wrote: > But anyway, this question is also orthogonal to whether we want to use > hg or git, no? Yes and no, it simplifies workflow reducing the importance of (i) and (ii) for external contributors, and the patches aren't living in long-term mercurial queues etc. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The power of accurate observation is commonly called cynicism by those who have not got it." George Bernard Shaw 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] hg workflow pointers
On 08/08/2017 03:27 PM, Kristian Fiskerstrand wrote: > that is added > as a single commit upon qmerge To avoid any ambiguity, this should be qfinish... qmerge is similar step in the Gentoo Portage process... -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Prævenire melius est quam præveniri It is better to precede than to be preceded 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] hg workflow pointers
On 08/08/2017 03:27 PM, Kristian Fiskerstrand wrote: > There are likely a few different questions resulting from this (my own > opinions in separate email). And here they come > (i) Should we use git for revision control instead of mercurial? I'm personally more involved in projects using git these days, I am however not sure if this constitute grounds for shifting up platform of its own, but I'm curious what other's think. Mercurial has some great features (a reason e.g facebook: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ uses it, although we don't exactly have a scaling issue) > (ii)(A) Should we continue to use bitbucket (it also supports git so > not dependent on (i)) or use another provider (if some of the questions > are regarding the UI of bitbucket / its use) (B) if not bitbucket, what > other alternative and why? Open question, I don't see an immediate reason to move except for group effects of most others using github so no need to have a new account. I don't necessarily see centralization as a good thing overall, nor do I like the github ToS > (iii) Should we submit patches to the mailing list for review instead > of using any platform's specific functionality? I do think we should use the mailing list more actively to get more involvement in the development; in particular with the low level of commits proper review can only be a good thing. This can likely also result in more complete commit message etc for individual commits with the discussion in email archives as reference. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "In politics stupidity is not a handicap." (Napoleon Bonaparte) 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] hg workflow pointers
On 08/01/2017 11:30 PM, Daniel Kahn Gillmor wrote: > Is there a comparably simple tutorial someone can point me to for > contributing to sks? > What I'm using myself, and is supported by bitbucket is mercurial patch queues (MQ extension) https://www.mercurial-scm.org/wiki/MqExtension / https://www.mercurial-scm.org/wiki/MqTutorial , which allows to push and pop from patch queue / qseries, allowing for separate commits within the patch series that isn't part of the regular master branch, that is added as a single commit upon qmerge ... That said... > or, would sks folks be interested in moving to git for revision control? There are likely a few different questions resulting from this (my own opinions in separate email). (i) Should we use git for revision control instead of mercurial? (ii)(A) Should we continue to use bitbucket (it also supports git so not dependent on (i)) or use another provider (if some of the questions are regarding the UI of bitbucket / its use) (B) if not bitbucket, what other alternative and why? (iii) Should we submit patches to the mailing list for review instead of using any platform's specific functionality? Now, (iii) possibly invalidates (i) and (ii) as the workflow is simplified (hg export), so in terms of the processes of commits and we'd avoid any move (wiki and issue tracker stays the same). -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aquila non capit muscas The eagle does not hunt flies 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] Dealing with abusive clients
On July 20, 2017 7:18:52 PM GMT+02:00, Valentin Sundermann wrote: >>>> Here's a quick excerpt from the logs: >>>> 216.241.59.205 - - [20/Jul/2017:14:46:51 +] "GET / HTTP/1.1" >200 >>>> 5285 "-" "-" >>>> 216.241.59.205 - - [20/Jul/2017:14:46:53 +] "GET / HTTP/1.1" >200 >>>> 5285 "-" "-" >>>> 216.241.59.205 - - [20/Jul/2017:14:46:56 +] "GET / HTTP/1.1" >200 >>>> 5285 "-" "-" >>>> 216.241.59.205 - - [20/Jul/2017:14:46:58 +] "GET / HTTP/1.1" >200 >>>> 5285 "-" "-" >>>> >>>> This particular client is making continuous requests for the main >page >>>> of my server every 2-3 seconds. They're not making any queries for >keys, >>>> submitting keys, etc., but are only requesting the main page. >>>> >>>> This has been going on since at least the 15th of July. >>>> >>>> I haven't observed any other odd traffic, so it seems unlikely that >a >>>> botnet is involved. Maybe a script that has gone awry? > >I see these requests too, but from a different IP. I noticed them 1-2 >months ago but wasn't able to find the origin of these requests (they >got sorted into a general logfile because of the "missing" Host field). > >The IP that is querying my server belongs to Amazon's AWS. Requests >look >the same, every 2 seconds a "GET /". > > >>> There might be a clue in the host header if you could log that? I >use >>> this nginx config to do that (and not log the client IP) >> >> Good idea. I'll see if I can tweak the logs. > >I log HTTP Host headers and it uses localhost in each requests. Still >no >idea what this could be. > >Best regards, >Valentin Sundermann Ditto, I'm also seeing similar requests from amazon ec2 -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] SKS Loadbalancing over DNS
On 07/15/2017 01:34 PM, Kristian Fiskerstrand wrote: > On 07/15/2017 11:39 AM, Moritz Wirth wrote: >> Good morning everybody, >> >> is it possible to loadbalance SKS/Nginx using multiple A records for the >> hostname? > > The keyserver pools operate as such DNS Round Robins. I wouldn't > generally recommend it for individual nameservers. > > (i) If the servers are in physical proximity (same DC), you're better > off with, in the case of nginx, usptream: > https://blog.sumptuouscapital.com/2013/10/load-balancing-sks/ > > (ii) if the servers are in different datacenters; use separate hostnames > to access the servers, using DNS RR for this will confuse monitoring of > the server (e.g otherwise both servers will drop if crawler hits the > down server, even if the other is operational, as there is no retry, as > opposed to what you get from upstream module), it also would impact > measuring for geographical pools etc.. so depending on level of > weirdness, could result in exclusion from the pool. > I should add that this goes for the individual servers and their hostnames specified, there is of course nothing stopping using a third domain name as a DNS round robin for two servers. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "The journey of a thousand miles begins with one step." (Lao Tzu) 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] SKS Loadbalancing over DNS
On 07/15/2017 11:39 AM, Moritz Wirth wrote: > Good morning everybody, > > is it possible to loadbalance SKS/Nginx using multiple A records for the > hostname? The keyserver pools operate as such DNS Round Robins. I wouldn't generally recommend it for individual nameservers. (i) If the servers are in physical proximity (same DC), you're better off with, in the case of nginx, usptream: https://blog.sumptuouscapital.com/2013/10/load-balancing-sks/ (ii) if the servers are in different datacenters; use separate hostnames to access the servers, using DNS RR for this will confuse monitoring of the server (e.g otherwise both servers will drop if crawler hits the down server, even if the other is operational, as there is no retry, as opposed to what you get from upstream module), it also would impact measuring for geographical pools etc.. so depending on level of weirdness, could result in exclusion from the pool. -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Aquila non capit muscas The eagle does not hunt flies 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] OCaml vs hyperthreading
On 06/26/2017 06:16 PM, Andrew Gallagher wrote: > Since SKS is written in OCaml, this might be of interest to keyserver > operators. This article might be of interest related to the intel microcode issue: https://tech.ahrefs.com/skylake-bug-a-detective-story-ab1ad2beddcd -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Money is better than poverty, if only for financial reasons." (Woody Allen) 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] OCaml vs hyperthreading
On 06/26/2017 06:16 PM, Andrew Gallagher wrote: > OCaml appears to make (dis?)optimisations that trigger a rare Intel > hyperthreading bug with increased probability. The way I'm reading it is; When ocaml breaks it is due to a processor misbehaving :) -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest." (Confucius) 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] Request: Install an efficient robots.txt file
On 06/23/2017 11:10 AM, robots.txt fan wrote: > metalgamer: Thank you very much! > > ToBeFree: It would sure serve the absurdity indeed. Please don't do > it. > > Kristian: Thank you very much for adding the file to the repository! > Like I explained, the concern are not bad actors here, but instead > actors that do respect the standard (e.g. Google). May I ask how the > git repository and the live site are related? While I see the > robots.txt file in the git repository, it is not displayed on > https://sks-keyservers.net/robots.txt. > Thank you for heads up, given that robots.txt wasn't previously tracked but created directly on server there ended up a conflict on update for the file... -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Money is better than poverty, if only for financial reasons." (Woody Allen) 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] Request: Install an efficient robots.txt file
On 06/22/2017 10:40 AM, robots.txt fan wrote: > Kristian, you have responded to this thread, I believe you manage the first > one on the list. Is there a reason why only /status is blocked and not /pks? > > https://sks-keyservers.net (blocks /status, but not /pks) The real reason is that /pks didn't exist when the robots.txt file was created, so I've [added it now], granted more for site resource management reasons than privacy reasons. From a privacy perspective robots.txt doesn't make sense, the data is already public, bad actors ignore robots.txt and crawl the site just the same; and the full data set is available and part of regular workflow for bootstrapping own servers. References: [added it now] https://git.sumptuouscapital.com/?p=sks-keyservers-pool.git;a=commit;h=b98e7522990961541165dfc23781a45a1a5e05a9 -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Whatever you do in life, surround yourself with smart people who'll argue with you." John Wooden 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] Request: Install an efficient robots.txt file
On 06/20/2017 05:56 PM, Ari Trachtenberg wrote: > Not quite ... each server can decide which keys it want s to accept. > Bad actors will eventually fall out of favor with the others. Now we presume a non-gossiping system of isolated servers -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Whenever you find yourself on the side of the majority, it is time to pause and reflect." (Mark Twain) 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] Request: Install an efficient robots.txt file
On 06/20/2017 04:15 PM, Ari Trachtenberg wrote: > What about instituting an e-mail check before accepting a key with an > e-mail? Then you're introducing an element of a certificate authority in the wrong place (and not all public keyblocks have emails as UID to begin with). -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "If you choose to sail upon the seas of banking, build your bank as you would your boat, with the strength to sail safely through any storm." (Jacob Safra (1891–1963)) 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] No IPv6
On 06/08/2017 09:46 AM, Kiss Gabor (Bitman) wrote: > Dear Kristian, > > Column 'IPv6' is fully red on page https://sks-keyservers.net/status/ > It seems your monitoring host lost its IPv6 connectivity. > Thanks for heads up, should be corrected again on next run -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Better to keep your mouth shut and be thought a fool than to open it and remove all doubt" (Mark Twain) 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] Long-form keyids and ocaml 4.02.3
On 06/05/2017 12:08 AM, Phil Pennock wrote: > No problems with cryptokit for me, using 1.7. I see from Mercurial > commit-log that this doesn't build with older versions of OCaml. It > looks like this comes down to being willing to specify which version > ranges of the OCaml releases we're supposed to work with. How far back, > at what price? The primary issue here is ocaml removing type definitions including ‘uint32’ from ocaml 4.03 as described in [0, 1]. which is used in cryptokit, which brings up the question of not embedding it in [2] References [0] https://bugs.gentoo.org/show_bug.cgi?id=591326 [1] https://caml.inria.fr/mantis/view.php?id=6517 [2] https://bitbucket.org/skskeyserver/sks-keyserver/issues/42/unbundle-cryptokit-sks-incompatible-with -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "There is no urge so great as for one man to edit another man's work." (Mark Twain) 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] Long-form keyids and ocaml 4.02.3
On 06/04/2017 03:26 AM, Phil Pennock wrote: > So we have newer-OCaml cleanup in the first branch "build-cleaner" and > then some desirable feature changes in a subordinate branch > "opt-long-keyids". > > Anyone with commit on the main repo want to consider merging these? Should be a pull request against the main repo for that. The build-cleaner patches are likely most interesting, and dkg has some work on it already. The last time I looked into it a number of the issues we're seeing in build is related to cryptokit, and we likely should discuss whether its time to dis-embed the library from the source ( https://bitbucket.org/skskeyserver/sks-keyserver/issues/42/unbundle-cryptokit-sks-incompatible-with ) to begin with. The 64 bit keyid references etc are not necessarily material, we use those for internal identifiers anyways but don't display it in the WebUI. One issue here is that people seem to put too much trustworthiness in the keyservers to begin with, which they shouldnt. So changes to the webui that gives the impression it is secure is a malservice. People should download the public keyblocks and do their own operations on them given their own trustdb/wot calculation rather than relying on a third party that doen't provide a security assertion to begin with. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Knowing is not enough; we must apply. Willing is not enough; we must do." (Johann Wolfgang von Goethe) 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] wserver_timeout value causing cascading failure?
On 05/05/2017 06:16 PM, Jonathon Weiss wrote: > > I've tested a number of compromise configurations. I'm not sure I've > resolved the cascading failure (time will tell) but I was wondering, if > I've solved the timeout problem on large keys. Could you re-test? > At least for the particular keyblock it now returns the full data. >> One thing that springs to mind is multiple instances of SKS behind the >> reverse proxy to distribute the load (I run two instances myself - and >> that is for lesser load). Would just need separate key port and do local >> reconciliation only between them necessary , can make sure stats page >> (?op=stats) only reaches the primary so it exposes the external peers on >> the reverse proxy. > > That was my slower to implement thought. Can you explain your > configuration in a little more detail? Do I understand correctly that > you're running multiple SKS instances on the same machine? Each with > their own copy of the DB? Is there any concern about polluting > https://sks-keyservers.net/status/ ? I guess all these same questions > apply if you have them on seperate VMs rather than the same machine. > In my case I'm running it on separate VMs, but the proposal is to run multiple instances, with separate DB copies, on the same machine, yes, as the overhead for multiple VMs isn't strictly necessary, but helps with failover during upgrades etc. As for pollution of the sks-keyservers.net data I solve this by always sending /pks/lookup?op=stats requests to the primary keyserver, that does external-facing reconciliation. The slave nodes only gossip internally to get the data, as such no need for multiple peers. Nodename was introduced for these setups, so hostname is the shared cluster addresse whereby nodename can be used to identify specific nodes. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Excellence is not a singular act but a habit. You are what you do repeatedly." (Shaquille O'Neal) 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] wserver_timeout value causing cascading failure?
On 04/24/2017 09:33 PM, Jonathon Weiss wrote: > Daniel, > > I'm pulling your questions into this thread, which I started before > seeing your mail: > > For reference, I can download this key without a problem. While I'm > topologically closer to pgp.mit.edu than you are, I believe the 1s > timeout should only count the time passing the info to Apache, not all > the way back to you (but please correct me if you think I'm wrong here). > If it is, in fact, taking more than 1s to transfer extremely large keys > from SKS to Apache, then I'm somewhat between a rock and a hard place > here. If you go back and try again now, are you still seeing the > problem? Fwiw, I'm still seeing it. > > As noted, I dropped this timeout form 4s to 1s last week to deal with > the cascading failure described below. > > The reverse proxy is Apache, but it is SKS' wserver_timeout that is set > to 1s. > > Any thoughts and advice would be welcome here. I have a couple, but > they are either of dubious effectiveness, or relatively drastic / much > slower to implement. > One thing that springs to mind is multiple instances of SKS behind the reverse proxy to distribute the load (I run two instances myself - and that is for lesser load). Would just need separate key port and do local reconciliation only between them necessary , can make sure stats page (?op=stats) only reaches the primary so it exposes the external peers on the reverse proxy. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "My father used to say: ‘Don’t raise your voice, improve your argument.’" (Desmond Tutu) 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] sks-keyserves.net Down?
On 04/14/2017 07:34 PM, Timothy A. Holtzen wrote: > Is it just me or has something gone wrong with sks-keyservers.net? I'm > seeing no status info on https://sks-keyservers.net/status/ and I'm not > getting a response when I try to resolve for pool.sks-keyservers.net. > Yes, it was an instance of a one line patch can never go wrong... -- ---- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 There are two tragedies in life. One is to lose your heart's desire. The other is to gain it. - George Bernard Shaw 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] ECC HTTPS certs for HKPS
[Sent from my iPad, as it is not a secured device there are no cryptographic keys on this device, meaning this message is sent without an OpenPGP signature. In general you should *not* rely on any information sent over such an unsecure channel, if you find any information controversial or un-expected send a response and request a signed confirmation] > On 3 Apr 2017, at 14:16, Pete Stephenson wrote: > > The systems I'm routinely seeing making bursts of queries seem to be > ordinary endpoints with dynamic IP addresses. They're not Tor exit > nodes, and essentially 100% of the queries they make result in a 404 > response -- it doesn't seem like someone refreshing a keyring with > keys that are known to exist. They're all using the same user-agent > too. googling the user agent [OkHttp] seems to be a client library for android. The first thing that strikes me with large refreshes without matching keys is either a separate set of keys not shared on the public network, it was one of those that leaked that caused 7,000 new keyblocks in a day or so historically at least, or if tied to cellphone maybe manual/QR exchanges without keyserver use.. But that is just observations based on historical events (and ultimately likely less relevant to how we should set up the network to cope) Referneces: [OkHttp] https://square.github.io/okhttp/ ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] ECC HTTPS certs for HKPS
On April 2, 2017 9:10:10 PM GMT+02:00, Pete Stephenson wrote: > >True, but RSA-4096 is *slow*. 3072 is a bit less so (but there's no >openssl speed option for testing it). > >My server, a cheap VPS at Scaleway, can only do 25.4 RSA-4096 private >key operations per second. It can do 192 RSA-2048 operations per >second. > >With ECC, it can do 2190 ECDSA P-256 signatures per second and 1430 >P-384 signatures. It can do 1190 and 382 P-256 and P-384 ECDH key >exchanges per second, respectively. > >That said, it's not a huge concern at present, as during peak times my >server only handles 3-5 TLS connections/second. Still, it seems that >some clients are particularly heavy-use (in particular, some German >and Finnish IP addresses using a user-agent of "okhttp/3.5.0" -- >anyone know what those are? Reverse DNS shows no particular clues: >some are DSL/cable connections, some are public hotspots, etc.) and >make periodic bursts of 10+ queries in a second, almost exclusively >for keys that don't exist. This means they're opening many >simultaneous, separate HTTPS connections with a fresh key exchange on >each. If they ramp up the number of connections they make (or there's >many new clients doing the same thing), this could pose scaling >problems. > >In the past there's been at least one corporate mail server that >queried the pool for each inbound email to see if the sender had a >public key. That caused a sustained increase in queries for a while, >but I don't see them anymore. > This part I find quite interesting to continue discussing, (i) it is likely of the more relevant as to whether to go ecc route. (ii) might raise question of need for setting minimum criteria for servers to be added to hkps pool etc. (iii) changes to usage patterns and preparation for more traffic As for (iii) we might be able to meet by adding more servers to hkps pool to get more distribution of load in addition to (ii) and (i) , but curious if others have identified interesting behavior from certain clients. As for gateway solutions , as far as I'm aware at least Symantec Encryption Server (former PGP Universal) only check LDAP (and not that either by default), but peripdic keyyring refreshes etc is natural behavior/usage anyways. -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP certificate at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] ECC HTTPS certs for HKPS
On 04/02/2017 06:00 PM, Pete Stephenson wrote: > On Sun, Apr 2, 2017 at 12:44 PM, Kristian Fiskerstrand > wrote: >> On 04/02/2017 07:07 AM, Phil Pennock wrote: >>> We need to know it won't break clients. So, setting up a keyserver >>> where dual-stack is present and asking people to point clients at it, >>> should help. >> >> In addition to not actually breaking clients, it'd be useful with some >> indication that added complexity has any value at all. In most cases ECC >> is lower security margin for lower interoperability. I'm still not >> convinced we have anything to gain by doing any dual-stack approach that >> also includes an increased workload to manage the certs. > > Out of curiosity, how would it be less interoperable? The whole point > of having the server choose is so that clients that support ECC would > get ECC certs, while those that don't would get RSA certs. Servers > aren't going to send an ECC cert to a client that doesn't advertise > ECC support. Let me elaborate on this as it is indeed a fair comment. The argument would be that, if RSA should not be used but ECC should for some reason, we should rather switch to only use ECC and not do dual stack, the main purpose would be not to duplicate key management task, so picking between the two, using RSA is still more operable than ECC -- hence preference for staying with RSA unless there are convincing arguments to the contrary. The only argument I can think of offhand is performance on embedded devices an implementations that potentially is less prone to side-channel attacks, none of which I necessarily believe are strong arguments in this particular case of TLS access to keyservers. > > I was curious about what key exchange mechanism (e.g. DHE, ECDHE, etc. > -- my server only supports ephemeral key exchange) and protocols (TLS > 1.0, 1.1, or 1.2) were being used by clients, so I have Apache keep > logs for a rolling 30-day window. If those logs would be of interest > to anyone (Phil?), I'd be happy to send suitably-anonymized (no IPs or > search queries) logs. In short, it appears that the vast majority of > client support ECDHE and prefer its use over DHE. > > Also, what do you mean by "lower security margin"? 2048-bit RSA keys > are equivalent to an ~80 bit symmetric cipher. A 256-bit ECC key is > equivalent to a 128-bit symmetric cipher. Sure, RSA keys, due to their > greater length, will succumb to quantum computers later than the > shorter ECC keys, but is that a plausible threat at the moment? if this is a worry we could use 3072 bit rsa keys (many are already 4096 bits) and yes, part of the thinking is the quantum computer resistance in that consideration. But I'm really more curious to arguments to switching to ecc in general :) > > Cheers! > -Pete > -- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 "Whatever you do in life, surround yourself with smart people who'll argue with you." John Wooden signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
