Re: Key server status

[Todd Fleisher]

That response means what you uploaded was already on the keyserver so it was 
ignored. I also see that key fingerprint on the keyserver, so if it wasn’t 
available on keyserver.ubuntu.com and your upload was ignored I’m not sure 
how/why it would suddenly be showing up @ 
https://keyserver.ubuntu.com/pks/lookup?search=0x05fa40b23af5025974c3b1a6c62aa8645d00d25b&fingerprint=on&op=index

I went ahead and uploaded a copy of it to my key servers so it will will sync 
with the rest of the peered network since we won’t peer with Canonical right 
now.

You may also want to update keys.openpgp.org which still has one of your now 
expired keys 
(https://keys.openpgp.org/vks/v1/by-fingerprint/DF16781A604A4F605F98B301F29BF36844FB7922)

-T

> On Mar 7, 2024, at 10:18, Skip Carter  wrote:
> 
> I just tried uploading to the ubuntu server. 2024-03-07 18::08 GMT
> uploading to the ubuntu server.  The response was:
> 
> {"inserted":null,"updated":null,"ignored":["rsa4096/05fa40b23af5025974c
> 3b1a6c62aa8645d00d25b"]}
> 
> I will check later if it sticks.
> 
> (For proper public access I also updated my key at keyserver.pgp.com
> 
> On Thu, 2024-03-07 at 09:54 -0800, Todd Fleisher wrote:
>> I would challenge that the ubuntu server is even well maintained for
>> day-to-day issues currently. My PGP key (0x 949D203A) was uploaded
>> directly to their server in the past as well as being available on my
>> nodes which they used to peer with. However, keyserver.ubuntu.com
>> began to intermittently respond with 404 not found errors when
>> searching for it (at least) almost 1 year ago when I began monitoring
>> it on May 1 2023. It remained that way until June 19, 2023  at which
>> point it started responding with 404 not found errors 100% of the
>> time as you can see here:
>> https://i.ibb.co/rcBJXbg/Screen-Shot-2024-03-07-at-09-45-53.png
>> 
>> I’d be curious to know if Skip or anyone else has had similar
>> experiences after trying to upload their key directly to canonical’s
>> server and then checking back to see if it is retained & made
>> available to clients that query for it.
>> 
>> Not to be totally negative, as Andrew is correct that we may finally
>> be making some progress with direct outreach to a new contact @
>> Canonical whereas even that failed in the past with individuals who
>> were responsible for their keyserver (e.g. handled peering requests
>> and the like). Fingers crossed.
>> 
>> -T
>> 
>>> On Mar 7, 2024, at 09:15, Andrew Gallagher via SKS development and
>>> deployment list  wrote:
>>> 
>>> On 7 Mar 2024, at 16:47, Skip Carter  wrote:
>>>> 
>>>> I have found that the keyservers are not properly synced:
>>>> 
>>>> The MIT server has my key from 2023-03-29
>>>> but the Ubuntu server has only my old expired key 2019-04-10 (4
>>>> years
>>>> out of date!).
>>> 
>>> The MIT server is effectively running unmaintained at the moment.
>>> It is a single-threaded sks-keyserver node with severe stability
>>> issues. We have tried engaging with them on several occasions but
>>> there has been no reply. I would not recommend relying upon it.
>>> 
>>> The Ubuntu keyserver is well-maintained for day to day issues, but
>>> there is some disconnect internally between their SRE teams and
>>> their support desk. We are making some progress and hope to be back
>>> in sync shortly.
>>> 
>>> You can see the current sync state of the graph at
>>> https://spider.pgpkeys.eu/graphs
>>> 
>>> A
>>> 
>> 
> 
> --
> Dr Everett (Skip) Carter 0xC62AA8645D00D25B
> s...@taygeta.com
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 
> 831-641-0645 x103
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Key server status

[Todd Fleisher]

I would challenge that the ubuntu server is even well maintained for day-to-day 
issues currently. My PGP key (0x 949D203A) was uploaded directly to their 
server in the past as well as being available on my nodes which they used to 
peer with. However, keyserver.ubuntu.com began to intermittently respond with 
404 not found errors when searching for it (at least) almost 1 year ago when I 
began monitoring it on May 1 2023. It remained that way until June 19, 2023  at 
which point it started responding with 404 not found errors 100% of the time as 
you can see here: 
https://i.ibb.co/rcBJXbg/Screen-Shot-2024-03-07-at-09-45-53.png

I’d be curious to know if Skip or anyone else has had similar experiences after 
trying to upload their key directly to canonical’s server and then checking 
back to see if it is retained & made available to clients that query for it.

Not to be totally negative, as Andrew is correct that we may finally be making 
some progress with direct outreach to a new contact @ Canonical whereas even 
that failed in the past with individuals who were responsible for their 
keyserver (e.g. handled peering requests and the like). Fingers crossed.

-T

> On Mar 7, 2024, at 09:15, Andrew Gallagher via SKS development and deployment 
> list  wrote:
> 
> On 7 Mar 2024, at 16:47, Skip Carter  wrote:
>> 
>> I have found that the keyservers are not properly synced:
>> 
>> The MIT server has my key from 2023-03-29
>> but the Ubuntu server has only my old expired key 2019-04-10 (4 years
>> out of date!).
> 
> The MIT server is effectively running unmaintained at the moment. It is a 
> single-threaded sks-keyserver node with severe stability issues. We have 
> tried engaging with them on several occasions but there has been no reply. I 
> would not recommend relying upon it.
> 
> The Ubuntu keyserver is well-maintained for day to day issues, but there is 
> some disconnect internally between their SRE teams and their support desk. We 
> are making some progress and hope to be back in sync shortly.
> 
> You can see the current sync state of the graph at 
> https://spider.pgpkeys.eu/graphs
> 
> A
> 



signature.asc
Description: Message signed with OpenPGP

Ubuntu/Canonical keyserver admin contact

[Todd Fleisher]

Is there anyone @ Canonical/Ubuntu or who can get me in touch with the 
person(s) in charge of keyserver.ubuntu.com  on 
this list? If so, could you please reach out to me off list? I sent an email to 
Paul Collins yesterday based on an email he sent about it back in 2019 but have 
not yet heard back and have something to discuss that is on a short timeline. 
Thanks in advance.

-T



signature.asc
Description: Message signed with OpenPGP

Re: keyserver.taygeta.com on hockeypuck

[Todd Fleisher]

If I recall from previous posts, hockeypuck has issues reconciling against 
nodes running SKS. I believe others took to running a separate SKS node to peer 
with nodes in the pool and then only peer locally between your own SKS node & 
hockeypuck node(s). Something like:

hockeypuck.taygeta.com <-> sks.taygeta.com <-> sks.pod01.fleetstreetops.com

-T

> On Aug 30, 2021, at 12:29, Skip Carter  wrote:
> 
> I am also getting lots of recon failed messages in the log, probably from dead
> peers.  Maybe we should post "I am still alive messages" here so we can
> reconfigure to use live peers.



signature.asc
Description: Message signed with OpenPGP

Re: shutdown of pgpkeys.co.uk and pgpkeys.uk

[Todd Fleisher]

Sorry to see it end this way, but to Dan’s point all the rugs are being pulled 
out from under this service. I will continue running my nodes, but it does seem 
like the official SKS key server network has reached the end of the road. As of 
yesterday, all of the pool DNS records were pulled. If you click through the 
expired SSL certificate to reach https://sks-keyservers.net/status/ 
 you will find this:

This service is deprecated. This means it is no longer maintained, and new HKPS 
certificates will not be issued. Service reliability should not be expected.

Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for 
the pool will no longer be provided at all.

-T

> On Jun 16, 2021, at 11:49, Daniel Austin  wrote:
> 
> Hi,
> 
> Due to the demise of the SKS pools and non-renewal of the SSL certs, i'm 
> shutting down pgpkeys.co.uk and pgpkeys.uk keyservers with immediate effect.
> 
> If you peer with either of them, please remove the entries from your 
> membership files.
> 
> It's been a good time, and i'm glad I could help over the years - but time is 
> over.
> 
> 
> Thanks,
> 
> Daniel.
> 



signature.asc
Description: Message signed with OpenPGP

Re: Key diff anomaly

[Todd Fleisher]

Hi Robert,
You may want to consider starting over once more after re-loading from a fresh 
key dump. Your server’s status page shows a total of 5,615,275, which is a 
delta of ~508,000 keys against the pool’s current mean. Having to process so 
many keys via the reconciliation process may put a strain on your peering 
partners. While many of the key dump sites have vanished, I believe you can get 
still pull a current one from some of the sources listed here: 
https://github.com/SKS-Keyserver/sks-keyserver/wiki/KeydumpSources#sources-of-keydumps

In particular, these look to be fully up to date:

https://mirror.cyberbits.eu/sks/dump/

https://keywin.trifence.ch/dumps/

http://pgp.uni-mainz.de/dump/

-T

> On Apr 6, 2021, at 12:08, Andreas Puls  wrote:
> 
> Hey Robbert,
> 
> Am 06.04.2021 um 18:53 schrieb Robbert Müller:
>> On 2021-04-05 17:25, Andreas Puls wrote:
>>> Hi all,
>>> 
>>> Am 05.04.2021 um 14:00 schrieb Robbert Müller:
 On 2021-04-05 07:46, Kiss Gabor (Bitman) wrote:
> I've just noticed that key diff of ALL current 26 pool members is
> negative.
> Meanwhile keyserver.snt.utwente.nl is dropped from the pool
> however it seems to be absolute healthy. Except its key diff: 73432.
> 
> I guess this this node got an attack-like burst of keys from outside.
> (And this 73k extra keys distorted the average so much that everybody
> else
> seems to be lacking thousands of keys.)
> 
> Gabor
 
 Hello,
 
 During an OS upgrade i botched the postgresql database, and wiped
 everything and loaded a keydump.
 This was saturday.
 
 Could, and if how,  this result in having more keys they the rest of the
 network ?
 
>>> That was my first thought. I had the same issue with a non full dump
>>> import and ran hockeypuck-pbuild twice.
>>> 
>>> But i think you killed your ptree too, right ? Maybe removing the ptree
>>> and rebuilding could fix it.
>> 
>> Hello,
>> 
>> 
>> Yeah, something was wrong here,
>> I wiped the ptree, and build it again with hockeypuck-pbuild, only now
>> i'm missing keys instead of having to many.
>> 
>> i've i'll see if the server will sync the keys back or that i have to
>> start over again.
>> 
> The sync will work but need some time. Make sure that your peering
> partner are working. Hockeypuck need some time to switch to another peer
> if one is not working.
> 
>> Robbert.
> 
> Br
>  Andreas
> 



signature.asc
Description: Message signed with OpenPGP

Re: Pool dried up

[Todd Fleisher]

> On Mar 23, 2021, at 02:38, Andrew Gallagher  wrote:
> 
> Hi, Todd.
> 
> On 23/03/2021 03:37, Todd Fleisher wrote:
>>> On Mar 22, 2021, at 13:28, Andrew Gallagher >> <mailto:andr...@andrewg.com>> wrote:
>>> 
>>> I happened to check the pool just now, and there are only three nodes in it:
>>> 
>>> 1pgpkeys.uk <http://pgpkeys.uk>[@]
>>> 2sks.pod01.fleetstreetops.com <http://sks.pod01.fleetstreetops.com>[@]
>>> 3sks.pod02.fleetstreetops.com <http://sks.pod02.fleetstreetops.com>[@]
> 
> BTW it has just happened again:
> 
> 1 pgpkeys.eu[@]
> 2 pgpkeys.uk[@]
> 3 sks.pod02.fleetstreetops.com[@]
> 
>>> Looking at the cached metadata it appears that when the spider ran, 
>>> pod02.fleetstreetops nodes was unavailable, as was pgpkeys.co.uk 
>>> <http://pgpkeys.co.uk> (the domain registration has expired).
>> I can’t speak for pgpkeys.co.uk <http://pgpkeys.co.uk>, but I have not seen 
>> any issues with sks.pod02.fleetstreetops.com 
>> <http://sks.pod02.fleetstreetops.com> (nor hkps.pool.sks-keyservers.net 
>> <http://hkps.pool.sks-keyservers.net>, which it powers) today.
> 
> Apologies, I didn't mean to cast doubt on the reliability of your node, but 
> rather on that of the spider. It does not maintain much of a historical 
> record, and so depends on a single measurement per node each hour for its 
> operation. This makes it very vulnerable to transient issues, such as 
> connection timeouts. One dropped connection, and 90% of the pool disappears 
> for an hour, even if all the nodes stay up.

No worries. I was neither offended nor trying to dispute  that at times the 
pools run thin (if not fully bottom out). I was just trying to keep the things 
in perspective. My nodes also suffer from issues periodically and as a result I 
have seen issues where they are non-responsive at times. This usually isn’t 
visible to the public on account of the load balanced setup.

> There are a few interlocking design issues at work here IMO, none of which 
> are the responsibility of individual operators.

Indeed.

-T

> --
> Andrew Gallagher
> 



signature.asc
Description: Message signed with OpenPGP

Re: Pool dried up

[Todd Fleisher]

> On Mar 22, 2021, at 13:28, Andrew Gallagher  wrote:
> 
> I happened to check the pool just now, and there are only three nodes in it:
> 
> 1 pgpkeys.uk[@]
> 2 sks.pod01.fleetstreetops.com[@]
> 3 sks.pod02.fleetstreetops.com[@]
> 
> Looking at the cached metadata it appears that when the spider ran, 
> pod02.fleetstreetops nodes was unavailable, as was pgpkeys.co.uk (the domain 
> registration has expired).

I can’t speak for pgpkeys.co.uk , but I have not seen 
any issues with sks.pod02.fleetstreetops.com 
 (nor hkps.pool.sks-keyservers.net 
, which it powers) today.

> pod01.fleetstreetops does not advertise any peers,

This happens intermittently when the non-recon node services the status 
request, but it is a multi-node pool so rest assured there is external 
reconciliation configured.

> This demonstrates that connectivity is a serious issue with the pool right 
> now. A few key nodes going down can orphan all other nodes, no matter how 
> well-behaved.

While the core idea behind this take is valid, I do not believe the current 
state of affairs is as dire as it is being portrayed.

> It should probably also be noted that pod02.fleetstreetops has been the only 
> node in the HKPS pool now for some time. This certainly can't be good for its 
> load.

Yes, this has been the case since last summer. This is completely reliant on 
Kristian’s continued signing of CSRs for member nodes.

-T



signature.asc
Description: Message signed with OpenPGP

Re: An evil idea :-)

[Todd Fleisher]

That looks more like a DNS CNAME, not a proxy. The same goes for this popular 
one:

keys.gnupg.net is an alias for hkps.pool.sks-keyservers.net.

-T

> On Mar 22, 2021, at 14:42, Andreas Puls  wrote:
> 
> 
> Am 22.03.2021 um 21:08 schrieb Kiss Gabor (Bitman):
>> One can decide to setup a proxy server without any own backend
>> but redirecting queries to some of the existing servers.
>> No one would recognize the cheating. :-)
>> 
> Looks like somebody already done that :)
> Just got a reuqest for the host "sks.undergrid.net"
> 
> $ host sks.undergrid.net
> sks.undergrid.net is an alias for pool.sks-keyservers.net.
> 
>> Gabor
>> 
> Andreas
> 



signature.asc
Description: Message signed with OpenPGP

Re: Seeking peers for openpgp.circl.lu

[Todd Fleisher]

Hi Alexandre,
Your statistics page does not show you have any keys loaded:

 Total number of keys: 0

By contrast, the current number I show is 6096841

You should download & import from a current key dump (e.g. 
https://pgp.key-server.io/sks-dump ) before 
requesting peers to reduce the number of keys that are handled by recon.

-T

> On Jan 20, 2021, at 01:22, Alexandre Dulaunoy  
> wrote:
> 
> Dear All,
> 
> We setup a new PGP key server https://openpgp.circl.lu/ to
> replace the old pgp.circl.lu.
> 
> The server is located in Luxembourg (Europe) hosted by CIRCL. The
> system is accessible via IPv4 and IPv6. The infrastructure
> is also peering with LU-CIX members.
> 
> openpgp.circl.lu 11370 # CIRCL - i...@circl.lu - 
> 0xca572205c0024e06ba70be89eaadcffc22bd4cd5
> 
> Our OpenPGP peering policy is open.
> 
> Thank you.
> 
> --
> Alexandre Dulaunoy
> CIRCL - Computer Incident Response Center Luxembourg
> 16, bd d'Avranches L-1160 Luxembourg
> i...@circl.lu - www.circl.lu - (+352) 247 88444
> 



signature.asc
Description: Message signed with OpenPGP

Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

[Todd Fleisher]

> On Oct 16, 2020, at 08:46, Skip Carter  wrote:
> 
> What are the characteristics of a poison key ?

A large number of bogus 3rd party signatures applied to the public key and 
uploaded to the network

> What makes it bad ?

The key size becomes too large for GPG to process it

> I wonder if there is an algorithmic way to deal with them instead of a
> blacklist.

This has been discussed to death on the list previously. Check the archives if 
you’d like more info. The short answer is no due to a lack of development 
resources. GNUPG has already mitigated against this by stripping 3rd party 
signatures & numerous GPG implementations have also moved to keys.openpgp.org 
 as the default keyserver in response to this issue.

-T

> --
> Dr Everett (Skip) Carter  0xF29BF36844FB7922
> s...@taygeta.com
> 
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: seeking peers for hyperboria.net.pl

[Todd Fleisher]

Adam,
You can also search the list archives for a thread with subject "SKS scaling 
configuration” which goes into detail about how to build a more robust pool of 
nodes to service requests. The software is far from perfect and you will likely 
see some errors even under “normal” operation. I wouldn’t worry about them 
unless they are causing specific issues.

Marcin,
Very cool info on your website, thanks for sharing.

-T

> On Oct 16, 2020, at 06:00, Adam Wojcieszonek  wrote:
> 
> Hi,
> Thanks for valuable suggestion. Today night will try with Varnish cache.
> 
> Dziękuję ,pozdrawiam serdecznie
> 
> Adam
> 
> 
> 
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
> piątek, 16 października 2020 12:41, Marcin Gondek  
> napisał(a):
> 
>> Hi,
>> 
>> https://fido.e-utp.net/display/EUTPNET/SKS+Server+Caching 
>> 
>> 
>> Maybe my old notes with dual SKS will help.
>> 
>> Thanks,
>> 
>> --
>> 
>> Marcin Gondek / Drixter
>> http://fido.e-utp.net/ <>
>> AS56662
>> 
>> 
>> 
>> 
>> 
>> Od: Sks-devel  w imieniu 
>> użytkownika Adam Wojcieszonek 
>> Wysłane: piątek, 16 października 2020 12:37
>> Do: sks-devel@nongnu.org 
>> Temat: Re: seeking peers for hyperboria.net.pl
>> 
>> Hi again
>> My server (Debian 9) is configured according to mrjones plip blog 
>> https://blog.plip.com/2018/06/29/deploying-a-pgp-sks-server-on-ubuntu-18-04/ 
>> 
>> Looks like similar to other configuration tutorials but as i observe my 
>> proxy is hanging every time. This causes srv is thrown every hour from the 
>> pool. Does anyone have an idea how to fix it ??
>> I've testet adding "retry=0" to web proxy configuration and also extend 
>> timeouts in apache2.conf by adding "Timeout 2400, ProxyTimeout 2400, 
>> ProxyBadHeader Ignore" but nothing changes. Can You give some examples of 
>> Apache configuration ? (tried also to search Google and this mailing list 
>> but no right fixes found for SKS).
>> I am also worried about errors in the log that I wrote about yesterday night.
>> 
>> br
>> 
>> Adam
>> 
>> 
>> 
>> 
>> Sks running few hours and I already have few questions.
>> I have traced syslog and can see frequently recurring event logs. Not sure 
>> something is wrong with sksconf ?
>> 
>> 1.
>> 
>> 
>> Oct 16 00:58:32 Khaos sks[10527]: 2020-10-16 00:58:32 99 keys received
>> Oct 16 00:59:32 Khaos sks[10526]: 2020-10-16 00:59:32 add_keys_merge failed: 
>> Eventloop.SigAlarm
>> Oct 16 00:59:32 Khaos sks[10526]: 2020-10-16 00:59:32 Key addition failed: 
>> Eventloop.SigAlarm
>> 
>> (last few hours see 0 updated keys in stats page  but DB folder size growing 
>> really fast  . After Eventloop.SigAlarm sks instance is unresponsive few 
>> minutes and cannot enter stats page)
>> 
>> 2.
>> Oct 16 00:52:11 Khaos sks[10526]: 
>> x-forwarded-server:keyserver.hyperboria.net.pl]): Sys_error("Connection 
>> reset by peer")
>> 
>> 3.
>> Oct 16 00:50:00 Khaos sks[771]: host:127.0.0.1:11371
>> Oct 16 00:50:00 Khaos sks[771]: pragma:no-cache
>> Oct 16 00:50:00 Khaos sks[771]: via:1.1 keyserver.hyperboria.net.pl:11371
>> Oct 16 00:50:00 Khaos sks[771]: x-forwarded-for:217.76.45.34
>> Oct 16 00:50:00 Khaos sks[771]: 
>> x-forwarded-host:pool.sks-keyservers.net:11371
>> Oct 16 00:50:00 Khaos sks[771]: 
>> x-forwarded-server:keyserver.hyperboria.net.pl]): Sys_error("Broken pipe")
>> 
>> Can someone explain me what above does it mean ?
>> 
>> Here is conf with addressess. IP's should be local , external IP or leave as 
>> it is 127.0.0.1 ?
>> # recon_address: 127.0.0.1
>> recon_port: 11370
>> hkp_address: 127.0.0.1 ::1
>> hkp_port: 11371
>> 
>> Adam
>> 
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

[Todd Fleisher]

> On Oct 15, 2020, at 17:58, Ángel  wrote:
> 
> First of all, those patches protect against a single poison key,
> 0xE41ED3A107A7DBC7. By skipping the merge of changes to it, I think.

I suppose one is better than none. I also block several other (popular?) keys 
that are problematic at the NGINX level after having issues with them in the 
past causing server instability. It’s far from a perfect system, but between 
that and automatic service restarts when SKS crashes I rarely have to touch 
anything anymore. *knocks on wood*

> Second, this may actually not be a good idea at all. sks key
> reconciliation works by having two servers with different contents for
> a "file" end up with the same one. If one of the parties is picky and
> reject some keys the other has, the system might fall apart.
> Ideally, a rejection of certain keys would have to be network-wide.
> Otherwise, the reconciliation could fail, or the servers might be
> continuously retrying that key which is actually rejected by the other
> party. I'm not sure if this is actually a problem with this patch (I
> hope someone better understanding the protocol can chime in and
> explain), but seems a reason for concern.
> Also, I expect that if you started from a dump which already has the
> forbidden key, this patch was probably a no-op and that reconciliation
> issue would go unnoticed.

Meh. I understand your thought process here, but don’t see it as a problem. At 
worst, servers will keep thinking they need to recon a problem key with a 
remote server that will never accept it. I cannot foresee how this would cause 
any real strain on the network no less to the point it might fall apart … any 
more so than it is already at risk of anyway.

-T

> Best regards
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

[Todd Fleisher]

For sure I’m not trying to preach to or convert anyone. Just (re-)offering my 
$0.02 regarding my experiences with SKS in particular. The same package would 
probably run just as well on Debian or maybe even other OS’s if you convert it 
to a native package. But since you brought it up … hopefully you get a laugh 
out of this classic adaptation:

When deep space exploration ramps up, it'll be the distributions that name 
everything, the Redhat Stellar Sphere, the Canonical Galaxy, Planet Debian. 


-T

> On Oct 15, 2020, at 12:30, Dan Egli  wrote:
> 
> But let's not get into a distro war.



signature.asc
Description: Message signed with OpenPGP

Re: seeking peers for hyperboria.net.pl

[Todd Fleisher]

I have placed a current dump @ 
https://sks.pod02.fleetstreetops.com/dump/2020-10-15/ if anyone needs it. 
Otherwise, recon will need to catch up 301,510 keys based on the stats pages of 
http://keyserver.hyperboria.net.pl:11371/pks/lookup?op=stats & other servers 
that are current in the network. Adam W’s server also lists 
epidemic.cs.cornell.edu 11370 in it’s membership file, but that hostname does 
not resolve in DNS. I would recommend he delete his current instance and start 
over with a current dump if he wants to participate in the pool. I would also 
urge operators to check the stats page of a new server requesting peering to 
ensure the delta is low before adding them to the network.

-T

> On Oct 14, 2020, at 20:54, Gabor Kiss  wrote:
> 
> On Wed, 14 Oct 2020, Adam Wojcieszonek wrote:
> 
>> - loaded dump from
>> keys.niif.hu/
>> (14.10.2020)
> 
> Folks,
> 
> FYI unfortunately the last successful dump was two months
> ago on keys.niif.hu.
> Since then some database corruption prevents dumping.
> 
> I delete the garbled files from the dump area right now.
> I hope at the weekend I'll have some spare time to rebuild
> the whole server from scratch.
> 
> Gabor
> 



signature.asc
Description: Message signed with OpenPGP

Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

[Todd Fleisher]

I personally recommend an Ubuntu 18.04LTS system, using the somewhat patched 
package found @ 
https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages 

 to protect against the so-called “poison keys” that will almost certainly 
cause your system to be unstable & use much more bandwidth & IO than is 
necessary. This path will render compilation unnecessary.

-T

> On Oct 14, 2020, at 20:40, Dan Egli  wrote:
> 
> On 10/14/2020 9:15 PM, Jeremy T. Bouse wrote:
>> Okay, so I have completed my move and finally had some time to take a look 
>> back at trying to get sks.undergrid.net  back 
>> online and started with trying to rebuild my Docker images which I found the 
>> build to be failing in part to the repo change. So I remembered the email 
>> here and updated my Dockerfile download location and got the build going 
>> again. I was of course getting the latest released version 1.1.6. This time 
>> when it built if failed with the following:
>> 
>> [ much deleted for brevity
>> 
>> So reading up some I see it was moved to be expected as an external link but 
>> couldn't see any updates to changes in the build pre-requirements. So anyone 
>> else ran into this and solved the build issues?
> I had a lot of problems getting SKS up and running. I finally found a good 
> idea after talking to some of the gentoo devs on IRC. Add net-misc/sks to 
> your /etc/portage/package.accept_keywords, then emerge sks again, it should 
> grab a DATED version of sks (sks_1.1.6_p20200624). That one compiled fine 
> where as all others seemed to want to die somewhere. Just be sure you have 
> the dev-ml/num package installed first, because that i will be needed and I 
> can't recall if this version includes that or not. Previous versions omitted 
> that dependency.
> 
> --
> Dan Egli
> On my Test server
> 



signature.asc
Description: Message signed with OpenPGP

Re: Sks-devel Digest, Vol 195, Issue 5

[Todd Fleisher]

Oops. Thanks for the update.

-T

> On Sep 10, 2020, at 5:19 PM, Jason John Schwarz  wrote:
> 
> The CVE issue is a hiccup in the page...if a server is offline it becomes 
> true.  I noticed that when I was doing some maintenance on my server one day.
> 
> Jason John Schwarz
> 
> 
> 
> 
>> On Sep 10, 2020, at 8:18 PM, Todd Fleisher > <mailto:t...@fleetstreetops.com>> wrote:
>> 
>> Good eye, I hadn’t noticed that one. The meta page also reports it is 
>> Vulnerable to CVE-2014-3207. While I think that alone will preclude it from 
>> being put into the pools even if it does resurface, I’d advise operators to 
>> remove the server from their membership files until that and the other 
>> issues are addressed/verified.
>> 
>> https://sks-keyservers.net/status/ks-status.php?server=keyserver.newideatest.site
>>  
>> <https://sks-keyservers.net/status/ks-status.php?server=keyserver.newideatest.site>
>> -T
>> 
>>> On Sep 10, 2020, at 3:39 PM, Jason John Schwarz >> <mailto:ja...@insect.com>> wrote:
>>> 
>>> It must have come up at least once and reported because it is showing up on 
>>> the SKS server list
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Sks-devel Digest, Vol 195, Issue 5

[Todd Fleisher]

Good eye, I hadn’t noticed that one. The meta page also reports it is 
Vulnerable to CVE-2014-3207. While I think that alone will preclude it from 
being put into the pools even if it does resurface, I’d advise operators to 
remove the server from their membership files until that and the other issues 
are addressed/verified.

https://sks-keyservers.net/status/ks-status.php?server=keyserver.newideatest.site
 

-T

> On Sep 10, 2020, at 3:39 PM, Jason John Schwarz  wrote:
> 
> It must have come up at least once and reported because it is showing up on 
> the SKS server list



signature.asc
Description: Message signed with OpenPGP

Re: Sks-devel Digest, Vol 195, Issue 5

[Todd Fleisher]

Has anyone actually been able to connect to keyserver.newideatest.site 
 on 11371 to verify the key counts or port 
11370 to verify recon is up & running? I’ve been unable get a response from 
either and my previous attempt to reply to one of Dan’s messages to this list 
returned a bounce back due to a misconfiguration on his mail server that points 
to it not being production ready:

 save to /var/spool/virtual/newideatest.site/dan/Maildir 

   generated by d...@newideatest.site 
   local delivery failed

The following text was generated during the delivery attempt:

-- save to /var/spool/virtual/newideatest.site/dan/Maildir 

  generated by d...@newideatest.site  --

Can't open log file /var/log/dovecot/debug.log: Permission denied
Reporting-MTA: dns; newideatest.site 

-T

> On Sep 10, 2020, at 9:10 AM, Jason John Schwarz via SKS development and 
> deployment list  wrote:
> 
> Dan,
> 
> I have added you to the peer list on keyserver.insect.com 
>  .  The peer string for our server is:
> 
> keyserver.insect.com    11370   # Jason 
> Schwarz mailto:ja...@insect.com>> 0x76626AA6
> 
> I tried to email you, but your site is actually blocking email from 
> insect.com  .
> 
> 
> Jason John Schwarz
> 
> 
> 
>> On Sep 10, 2020, at 12:00 PM, sks-devel-requ...@nongnu.org 
>>  wrote:
>> 
>> Send Sks-devel mailing list submissions to
>>  sks-devel@nongnu.org 
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://lists.nongnu.org/mailman/listinfo/sks-devel
>> or, via email, send a message with subject or body 'help' to
>>  sks-devel-requ...@nongnu.org
>> 
>> You can reach the person managing the list at
>>  sks-devel-ow...@nongnu.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Sks-devel digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. Need recon partners (Dan Egli)
>>   2. Re: Need recon partners (iaren...@escomposlinux.org)
>> 
>> 
>> --
>> 
>> Message: 1
>> Date: Thu, 10 Sep 2020 00:03:22 -0600
>> From: Dan Egli 
>> To: sks-devel@nongnu.org
>> Subject: Need recon partners
>> Message-ID: 
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
>> I asked once before, but only one person responded. So let me try again.
>> I'm looking for people to partner with for sks reconciliation. If you
>> are willing to sync with me, add keyserver.newideatest.site 11370 to
>> your partner list and let me know what I should add to mine. I'd really
>> like to get some gossip partners here.
>> 
>> 
>> Thanks!
>> 
>> --- Dan
>> 
>> 
>> 
>> 
>> --
>> 
>> Message: 2
>> Date: Thu, 10 Sep 2020 10:42:29 +0200
>> From:  ( Iñaki Arenaza)
>> To: Dan Egli via SKS development and deployment list
>>  
>> Subject: Re: Need recon partners
>> Message-ID: <87a6xynhu2@osgiliath.escomposlinux.org>
>> Content-Type: text/plain; charset="utf-8"
>> 
>> On jue, sep 10 2020, Dan Egli via SKS development and deployment list wrote:
>> 
>> Hi Dan,
>> 
>>> I asked once before, but only one person responded. So let me try
>>> again. I'm looking for people to partner with for sks
>>> reconciliation. If you are willing to sync with me, add
>>> keyserver.newideatest.site 11370 to your partner list and let me know
>>> what I should add to mine. I'd really like to get some gossip partners
>>> here.
>> 
>> I have just added your server to ours. If you want to add our server to
>> yours, here are the details:
>> 
>> # PGP Key Server Administrator  
>> 0x9494EB8D619AFE032AD1C2DCBE84550A2578867D
>> keyserver.escomposlinux.org 11370
>> 
>> Best regards,
>> Iñaki.
>> -- next part --
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 832 bytes
>> Desc: not available
>> URL: 
>> 
>> 
>> --
>> 
>> Subject: Digest Footer
>> 
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
>> 
>> 
>> --
>> 
>> End of Sks-devel Digest, Vol 195, Issue 5
>> *
> 



signature.asc
Description: Message signed with OpenPGP

Re: DB error in crontab

[Todd Fleisher]

It seem you may have a Berkley DB problem on your system. From 
https://web.stanford.edu/class/cs276a/projects/docs/berkeleydb/api_c/log_archive.html
 
:
Errors

The DB_ENV->log_archive method may fail and return a non-zero error for the 
following conditions:

EINVAL
An invalid flag value or parameter was specified.
The log was corrupted.

The DB_ENV->log_archive method may fail and return a non-zero error for errors 
specified for other Berkeley DB and C library or system functions. If a 
catastrophic error has occurred, the DB_ENV->log_archive method may fail and 
return DB_RUNRECOVERY 
,
 in which case all subsequent Berkeley DB calls will fail in the same way.

I’d recommend checking that your DB is not corrupt and consider re-building it 
to see if you have better luck. You might also want to see if 
re-building/installing the SKS software on the system helps. I’m using the 
bionic package from: 
https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages 

 so no build was required and I have not had any issues with the same cron job.

-T

> On Sep 5, 2020, at 16:39, Dan via SKS development and deployment list 
>  wrote:
> 
> Not on my end. Watch:
> 
> root@jupiter:/var/lib/sks# db_archive -d -h PTree
> db_archive: BDB1566 DB_ENV->log_archive interface requires an environment 
> configured for the logging subsystem
> db_archive: DB_ENV->log_archive: Invalid argument
> 
> On 9/5/2020 5:35 PM, Skip Carter wrote:
>> What args are you using ?
>> 
>> For me:   db_archive -d -h PTree
>> just silently runs with no errors
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Desperately Seeking Kristian - SKS HKPS certificate renewals

[Todd Fleisher]

I posted a reply noting it’s not clear from the GitHub issue whether they were 
trying to contact the HKPS pool or trying to access the non-HKPS pool with SSL. 
In the linked Endeavour thread, Ben mentions:
It appears to be an error with the SSL certificate of pool.sks-keyservers.net 
. The server is providing a certificate for 
pgp.ocf.berkeley.edu.

EDIT: The certificate is also expired.

That will never work, because pool.sks-keyservers.net 
 only supports unencrypted connections when 
using the CNAME. Going to an individual server in the pool and trying to use 
HKPS/HTTPS (e.g. hkps://pgp.ocf.berkeley.edu) might work on it’s own assuming 
it has a publicly trusted SSL certificate configured. And unless the OCF 
keyserver admins had to intervene an manually update it looks like their Lets 
Encrypt SSL certificate should have been valid 5 days ago when that thread was 
created as it was minted over a month prior on June 23, 2020.

-T

> On Aug 2, 2020, at 22:33, ygrek  wrote:
> 
> Hi,
> 
> there was a report of expired certificate: 
> https://github.com/SKS-Keyserver/sks-keyserver/issues/81
> 
> --
> 



signature.asc
Description: Message signed with OpenPGP

Re: Desperately Seeking Kristian - SKS HKPS certificate renewals

[Todd Fleisher]

FYI - the SKS certificate for sks.pod02.fleetstreetops.com 
<http://sks.pod02.fleetstreetops.com/> has now been renewed so it is back in 
service for the hkps.pool.sks-keyservers.net 
<http://hkps.pool.sks-keyservers.net/> CNAME as of ~2138 UTC.

-T

> On Jun 22, 2020, at 10:55, Todd Fleisher  wrote:
> 
> FYI - the SKS certificate for sks.pod02.fleetstreetops.com 
> <http://sks.pod02.fleetstreetops.com/> has now expired and been replaced with 
> a standard SSL certificate from Let’s Encrypt as of 1646 UTC. As such, it 
> will no longer be able to field requests for the hkps.pool.sks-keyservers.net 
> <http://hkps.pool.sks-keyservers.net/> CNAME. While I was writing this I see 
> the DNS CNAME has updated so I should stop receiving requests I cannot 
> service without a new certificate.
> 
> 25 days until Dan Austin’s certificates expire on the remaining nodes in the 
> pool.
> 
> -T
> 



signature.asc
Description: Message signed with OpenPGP

Re: Desperately Seeking Kristian - SKS HKPS certificate renewals

[Todd Fleisher]

FYI - the SKS certificate for sks.pod02.fleetstreetops.com 
<http://sks.pod02.fleetstreetops.com/> has now expired and been replaced with a 
standard SSL certificate from Let’s Encrypt as of 1646 UTC. As such, it will no 
longer be able to field requests for the hkps.pool.sks-keyservers.net CNAME. 
While I was writing this I see the DNS CNAME has updated so I should stop 
receiving requests I cannot service without a new certificate.

25 days until Dan Austin’s certificates expire on the remaining nodes in the 
pool.

-T

> On Jun 11, 2020, at 11:13, Todd Fleisher  wrote:
> 
> Hi all,
> Has anyone seen or heard from Kristian in the last month or so? I’ve reached 
> out several times off list about the upcoming expiration of my server’s 
> certificate for the HKPS pool but have not received any response. My 
> certificate expires in 10 days, at which point I will no longer be able to 
> serve requests for hkps.pool.sks-keyservers.net 
> <http://hkps.pool.sks-keyservers.net/> and will have to generate my own 
> certificate so other clients can continue to securely access my server 
> directly. Also, the SKS HKPS certificates of the only other servers in the 
> pool expire in 36 days. If new certificates are not minted by that time the 
> SKS HKPS pool will become defunct. If anyone has other channels by which to 
> reach Kristian, please use them to reach out and make sure he is OK & aware 
> of this impending issue.
> 
> SSL WARNING - Certificate 'sks.pod02.fleetstreetops.com 
> <http://sks.pod02.fleetstreetops.com/>' expires in 10 day(s) (2020-06-22 
> 09:47 -0700/PDT).
> SSL WARNING - Certificate 'pgpkeys.uk <http://pgpkeys.uk/>' expires in 36 
> day(s) (2020-07-17 11:43 -0700/PDT).
> SSL WARNING - Certificate 'pgpkeys.eu <http://pgpkeys.eu/>' expires in 36 
> day(s) (2020-07-17 11:42 -0700/PDT).
> SSL WARNING - Certificate 'pgpkeys.co.uk <http://pgpkeys.co.uk/>' expires in 
> 36 day(s) (2020-07-17 11:41 -0700/PDT).
> 
> -T
> 



signature.asc
Description: Message signed with OpenPGP

Re: Desperately Seeking Kristian - SKS HKPS certificate renewals

[Todd Fleisher]

Thanks for the suggestion, Gabor. He doesn’t appear to have been active there 
since last summer, but it can’t hurt to try.

-T

> On Jun 11, 2020, at 21:19, Gabor Kiss  wrote:
> 
> On Thu, 11 Jun 2020, Todd Fleisher wrote:
> 
>> Has anyone seen or heard from Kristian in the last month or so? I?ve reached
> 
>> SKS HKPS pool will become defunct. If anyone has other channels by which to
>> reach Kristian, please use them to reach out and make sure he is OK & aware
>> of this impending issue.
> 
> https://mobile.twitter.com/krifisk
> 
> Gabor
> 



signature.asc
Description: Message signed with OpenPGP

Desperately Seeking Kristian - SKS HKPS certificate renewals

[Todd Fleisher]

Hi all,
Has anyone seen or heard from Kristian in the last month or so? I’ve reached 
out several times off list about the upcoming expiration of my server’s 
certificate for the HKPS pool but have not received any response. My 
certificate expires in 10 days, at which point I will no longer be able to 
serve requests for hkps.pool.sks-keyservers.net 
 and will have to generate my own 
certificate so other clients can continue to securely access my server 
directly. Also, the SKS HKPS certificates of the only other servers in the pool 
expire in 36 days. If new certificates are not minted by that time the SKS HKPS 
pool will become defunct. If anyone has other channels by which to reach 
Kristian, please use them to reach out and make sure he is OK & aware of this 
impending issue.

SSL WARNING - Certificate 'sks.pod02.fleetstreetops.com' expires in 10 day(s) 
(2020-06-22 09:47 -0700/PDT).
SSL WARNING - Certificate 'pgpkeys.uk' expires in 36 day(s) (2020-07-17 11:43 
-0700/PDT).
SSL WARNING - Certificate 'pgpkeys.eu' expires in 36 day(s) (2020-07-17 11:42 
-0700/PDT).
SSL WARNING - Certificate 'pgpkeys.co.uk' expires in 36 day(s) (2020-07-17 
11:41 -0700/PDT).

-T



signature.asc
Description: Message signed with OpenPGP

Re: Updated GPG Key

[Todd Fleisher]

Thanks Wiktor, that did the trick:

gpg: requesting key from 
'https://gentoo.org/.well-known/openpgpkey/hu/gd818fuu6rmaro6q6qqdtffzzagppfwo?l=k_f'
gpg: key 0x0B7F8B60E3EDFAE3: "Kristian Fiskerstrand 
" 7 new signatures
gpg: key 0x0B7F8B60E3EDFAE3: "Kristian Fiskerstrand 
" 1233 signatures cleaned
gpg: Total number processed: 1
gpg: new signatures: 7
gpg: signatures cleaned: 1233
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:  25  signed: 868  trust: 0-, 0q, 0n, 0m, 0f, 25u
gpg: depth: 1  valid: 868  signed:  65  trust: 866-, 1q, 0n, 0m, 1f, 0u
gpg: next trustdb check due at 2020-05-23

-T

> On May 21, 2020, at 12:45, Wiktor Kwapisiewicz  wrote:
> 
> On 21.05.2020 20:31, Todd Fleisher wrote:
>> Cc’ing the list in case someone else has a good, current copy of it and
>> could send it my way.
> 
> Kristian's key can be retrieved through Gentoo's Web Key Directory:
> 
> Check list of developers here:
> https://gentoo.org/inside-gentoo/developers/
> 
> Kristian's user name is "k_f".
> 
> Funny thing that when I do "gpg --locate-key k...@gentoo.org" it says
> "WKD: Provided object is too large" (the key is 412kB) but you can fetch
> it manually from the WKD endpoint with:
> 
> $ gpg --fetch-key
> "https://gentoo.org/.well-known/openpgpkey/hu/gd818fuu6rmaro6q6qqdtffzzagppfwo?l=k_f";
> 
> I had hoped the instructions would be more straightforward when I
> remembered about the Gentoo WKD installation but well... at least it works.
> 
> Have a nice evening!
> 
> Kind regards,
> Wiktor
> 
> --
> https://metacode.biz/@wiktor
> 



signature.asc
Description: Message signed with OpenPGP

Updated GPG Key

[Todd Fleisher]

Hi Kristian,
The copy of your GPG key I have expired at the end of last year & the copy 
available via the SKS network is 27MB which indicates it has been poisoned with 
bogus signatures. Can you please send an updated copy of your key and/or upload 
it to keys.openpgp.org  or your website or WKD or 
somewhere public for people to obtain it?

Cc’ing the list in case someone else has a good, current copy of it and could 
send it my way.

Thanks in advance,
-T



signature.asc
Description: Message signed with OpenPGP

Re: 6 million

[Todd Fleisher]

> On Apr 14, 2020, at 14:32, Stefan Claas  wrote:
> 
> I don't know why they are saying this, but if you would download my CA 
> certified
> public key block from their server, the CA sig3 is on my public key block.

If I had to guess, I’d say they allow you to upload your own public key and 
don’t strip away any third party signatures you may have included in your 
upload. So if I wanted to sign your key I would have to do so, then send it to 
you to re-upload and re-confirm before it would be published. While this likely 
isn’t a big deal for the more tech-savvy folks out there who are already 
familiar with GPG, others would struggle with or just ignore it and not have 
any 3rd party signatures.

> Another thing I like about the Mailvelope keyserver is that when you upload 
> your
> public key block, they will send you an encrypted email, with a validation 
> link,
> so that your public key block is only available there, once you have confirmed
> the link.

This is what Hagrid does as well, minus the encrypted email part. And while it 
does provide a useful privacy/control function, it does increase the complexity 
(or at least the user touch points) as mentioned above.

-T



signature.asc
Description: Message signed with OpenPGP

Re: 6 million

[Todd Fleisher]

> On Apr 14, 2020, at 12:35, brent s.  wrote:
> 
>> Excuse me if I sound like a troll. It is a valid question, because as you
>> may know public keys on SKS keyservers can be knocked out or not so nice
>> data can be added to them, thus not protecting users key.
> 
> That is not how any of the attacks work. At all. A keyserver can be
> brought down but that doesn't magically put the integrity of the keys at
> risk to tampering. (If it did, you'd have an issue with GnuPG or PGP,
> not SKS.) Users' keys are protected just fine.

Maybe I’m interpreting it differently, but I think Brent brings up a fair point 
here. The so-called “posoined keys” with thousands of (bogus) signatures in SKS 
are rendered useless. This happened to my key last year so now people have to 
obtain it from other locations outside of SKS. I’m actually glad there are 
alternate key server environments that help meet this need even if I don’t like 
other things about said key servers.

> On Apr 14, 2020, at 12:46, Stefan Claas  wrote:
> 
> Todd Fleisher wrote:
> 
>> So much this. Some of us have a legitimate need for what SKS provides that
>> can’t be accommodated by the new kids on the block like Hagrid & Mailvelope.
>> Neither supports third party signatures and the web of trust. I’ve reached
>> out to the Hagrid team about that & peering but  People also seem to still be
>> actively using SKS for new & updated keys as well, based on the stats page.
> 
> I have talked last year with the Mailvelope guys about other things, but they
> are very friendly. And I like to point out that Mailvelope keeps your
> Signatures and is probably the most secure key server as of today. The only
> thing missing AFAIK is the peering capabilities that SKS has, but I could
> imagine if you guys would show your support to the Mailvelope keyserver, the
> developemnt team would listen. At least worth a try.

That’s good to hear. I’ve heard of Mailvelope, but haven’t really looked at it 
yet. Their site does specifically say “No Web of Trust” though, so I’m not sure 
it’s accurate to say they support third party signatures.

However, there are other issues I’m already seeing where people & GPG software 
packages are moving from SKS to Hagrid. Since the keys exist in both places, 
but likely will only get updated on the “newer” key server you have to know 
where to look for their most current key. There’s also Flowcrypt that maintains 
their own key server, so I’m a little hesitant to say it’s a good thing to add 
yet another key server to the mix for public consumption.

Finally, I know Hagrid doesn’t support wildcard domain searches. You have to 
know exactly what email address or GPG key ID you are looking for. This is also 
currently a show stopper for me as I use that combined with the web of trust to 
discover and validate keys for multiple domains.

> On Apr 14, 2020, at 13:01, Stefan Claas  wrote:
> 
> I do not want to manipulate people('s opinion) and I am fine that you guys
> still operate your services, even if I can't understand why.

I think the simplest explanation is because people need and are using it (as 
seen in these stats from my 2 environments: https://imgur.com/a/cQ2Kr5h 
<https://imgur.com/a/cQ2Kr5h>). Also, in my experience, it currently doesn’t 
take much time, effort, or resources on my end to keep it going. It’s certainly 
less effort leaving it in place than tearing it all down, but the real reason 
is it serves a useful function.

-T



signature.asc
Description: Message signed with OpenPGP

Re: 6 million

[Todd Fleisher]

> On Apr 14, 2020, at 10:29, brent s.  wrote:
> 
>> What benefits do you have as an SKS operator, to still support such
>> old and dangerous GnuPG/SKS client-server model, in 2020?
> 
> Are you on this list just to troll or do you have anything useful to say?

So much this. Some of us have a legitimate need for what SKS provides that 
can’t be accommodated by the new kids on the block like Hagrid & Mailvelope. 
Neither supports third party signatures and the web of trust. I’ve reached out 
to the Hagrid team about that & peering but  People also seem to still be 
actively using SKS for new & updated keys as well, based on the stats page.

> On Apr 7, 2020, at 09:10, Skip Carter  wrote:
> 
> This group's name "sks-devel" is historical no one appears to want to
> admit actually developer; we are actually sks-admins that spend a lot
> of time keeping the plates spinning.

I have spent hardly any time keeping my SKS VMs operational for some time now 
(knock on wood). The last 2 issues I had were some VMs dropping out due to an 
underlying hardware problem unrelated to SKS even. I’ve posted about my 
configuration before on the list back on February 17, 2019 if you or anyone 
else is interested in improving your setup and possibly freeing up your time 
for other things.

-T



signature.asc
Description: Message signed with OpenPGP

Re: hkps.pool.sks-keyservers.net DNS failing to resolve

[Todd Fleisher]

Hi Kristian,
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 <https://sks-keyservers.net/ca/crl.pem>

-T

> On Jan 15, 2020, at 2:19 AM, Kristian Fiskerstrand 
>  wrote:
> 
> 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: Message signed with OpenPGP

Re: hkps.pool.sks-keyservers.net DNS failing to resolve

[Todd Fleisher]

Hi David,
That’s correct … https://i.imgur.com/eOBk0Sp.gifv 
<https://i.imgur.com/eOBk0Sp.gifv> … https://i.imgur.com/40Ekopq.jpg 
<https://i.imgur.com/40Ekopq.jpg>

Hopefully Kristian finds and fixes his issue in the morning.

-T

> On Jan 14, 2020, at 5:17 PM, David Moes  wrote:
> 
> Hi Todd,
> 
> For HPKS you must be added by Kristian to his self signed cert, without
> this you don't get listed as HPKS-capable node.
> 
> David.
> 
> Am 15.01.2020 um 02:05 schrieb Todd Fleisher:
>> Hi David,
>> Good catch, that would explain it. I suspect Kristian’s script that
>> checks the potential HKPS nodes in order to update the DNS record is
>> failing and/or not running. I have confirmed my HKPS-capable nodes/pool
>> respond to queries & key uploads, but I’m not sure what criteria he is
>> checking on his end. FWIW, I do see recent “pings” from his IP address
>> against nodes/pool as well (UTC timestamps):
>> 
>>Jan 14 23:34:40 sks05 sks[17211]: 2020-01-14 23:34:40 Error handling
>>request (POST,/pks/add,[
>>Jan 14 23:34:40 sks05 sks[17211]: accept:*/*
>>Jan 14 23:34:40 sks05 sks[17211]: connection:close
>>Jan 14 23:34:40 sks05 sks[17211]: content-length:82
>>Jan 14 23:34:40 sks05 sks[17211]:
>>content-type:application/x-www-form-urlencoded
>>Jan 14 23:34:40 sks05 sks[17211]: host:sks_servers
>>Jan 14 23:34:40 sks05 sks[17211]: x-forwarded-for:37.191.231.105,
>>10.x.x.x]): Failure("Error while decoding ascii-armored key: text
>>terminated before beginning of ascii block”)
>> 
>> 
>> -T
>> 
>>> On Jan 14, 2020, at 4:47 PM, David Moes >> <mailto:v...@unix.lu>> wrote:
>>> 
>>> Hi Todd,
>>> 
>>> This is probably because there is no server in the pool at the moment
>>> that has HKPS.
>>> 
>>> Check the status: https://sks-keyservers.net/status/ - (HKPS RED)
>>> 
>>> Kind regards,
>>> 
>>> David.
>>> 
>>> Am 15.01.2020 um 00:25 schrieb Todd Fleisher:
>>>> Hi Kristian,
>>>> Starting @ 01-14-2020 20:45:18 UTC it seems DNS is failing to resolve
>>>> successfully, with the public resolvers & NS-GLOBAL.KJSL.COM
>>>> <http://NS-GLOBAL.KJSL.COM>
>>>> <http://NS-GLOBAL.KJSL.COM> returning NXDOMAIN & the remaining
>>>> authoritative servers for the returning REFUSED.
>>>> 
>>>> Results can be seen here: https://pastebin.com/raw/JweLJyYL
>>>> 
>>>> -T
>>>> 
>>> 
>>> --
>>> David Moes
>>> Public OpenPGP 0xFBDD7EAAEDD53063 key at hkp://pgp.mit.edu
>>> fpr: 550C D308 CC0D 1CE1 79D4  EAA0 233D B73F 31B9 7723
>>> 
>>> “Logic will get you from A to Z; imagination will get you everywhere.”
>>> 
>>> ― Albert Einstein
>>> <0xFBDD7EAAEDD53063.asc>
>> 
> 
> --
> David Moes
> Public OpenPGP 0xFBDD7EAAEDD53063 key at hkp://pgp.mit.edu
> fpr: 550C D308 CC0D 1CE1 79D4  EAA0 233D B73F 31B9 7723
> 
> “Logic will get you from A to Z; imagination will get you everywhere.”
> 
> ― Albert Einstein
> <0xFBDD7EAAEDD53063.asc>



signature.asc
Description: Message signed with OpenPGP

Re: hkps.pool.sks-keyservers.net DNS failing to resolve

[Todd Fleisher]

Hi David,
Good catch, that would explain it. I suspect Kristian’s script that checks the 
potential HKPS nodes in order to update the DNS record is failing and/or not 
running. I have confirmed my HKPS-capable nodes/pool respond to queries & key 
uploads, but I’m not sure what criteria he is checking on his end. FWIW, I do 
see recent “pings” from his IP address against nodes/pool as well (UTC 
timestamps):

Jan 14 23:34:40 sks05 sks[17211]: 2020-01-14 23:34:40 Error handling request 
(POST,/pks/add,[
Jan 14 23:34:40 sks05 sks[17211]: accept:*/*
Jan 14 23:34:40 sks05 sks[17211]: connection:close
Jan 14 23:34:40 sks05 sks[17211]: content-length:82
Jan 14 23:34:40 sks05 sks[17211]: content-type:application/x-www-form-urlencoded
Jan 14 23:34:40 sks05 sks[17211]: host:sks_servers
Jan 14 23:34:40 sks05 sks[17211]: x-forwarded-for:37.191.231.105, 10.x.x.x]): 
Failure("Error while decoding ascii-armored key: text terminated before 
beginning of ascii block”)

-T

> On Jan 14, 2020, at 4:47 PM, David Moes  wrote:
> 
> Hi Todd,
> 
> This is probably because there is no server in the pool at the moment
> that has HKPS.
> 
> Check the status: https://sks-keyservers.net/status/ - (HKPS RED)
> 
> Kind regards,
> 
> David.
> 
> Am 15.01.2020 um 00:25 schrieb Todd Fleisher:
>> Hi Kristian,
>> Starting @ 01-14-2020 20:45:18 UTC it seems DNS is failing to resolve
>> successfully, with the public resolvers & NS-GLOBAL.KJSL.COM
>> <http://NS-GLOBAL.KJSL.COM> returning NXDOMAIN & the remaining
>> authoritative servers for the returning REFUSED.
>> 
>> Results can be seen here: https://pastebin.com/raw/JweLJyYL
>> 
>> -T
>> 
> 
> --
> David Moes
> Public OpenPGP 0xFBDD7EAAEDD53063 key at hkp://pgp.mit.edu
> fpr: 550C D308 CC0D 1CE1 79D4  EAA0 233D B73F 31B9 7723
> 
> “Logic will get you from A to Z; imagination will get you everywhere.”
> 
> ― Albert Einstein
> <0xFBDD7EAAEDD53063.asc>



signature.asc
Description: Message signed with OpenPGP

hkps.pool.sks-keyservers.net DNS failing to resolve

[Todd Fleisher]

Hi Kristian,
Starting @ 01-14-2020 20:45:18 UTC it seems DNS is failing to resolve 
successfully, with the public resolvers & NS-GLOBAL.KJSL.COM returning NXDOMAIN 
& the remaining authoritative servers for the returning REFUSED.

Results can be seen here: https://pastebin.com/raw/JweLJyYL 


-T



signature.asc
Description: Message signed with OpenPGP

Re: The state of peer connectivity

[Todd Fleisher]

Is this the one you are remembering: 
https://github.com/Timi7007/SKS-Keyserver-Gossip-Network-Graph 
 ?

-T

> On Dec 31, 2019, at 6:58 AM, Andreas Puls  wrote:
> 
> Hey Skip,
> 
> nice work.
> 
> I remember that another User wrote a JavaScript? and HTML where all
> servers are listed with their peering. Unfortunately i can't find the
> link anymore :(
> 
> Br
>  Andreas
> 
> Am 20.12.2019 um 18:55 schrieb Skip Carter:
>> Hi,
>> 
>> Following the loss of half my peers last week (thank you to all that
>> added me afterwards). I wondered just what the state of peer
>> connectivity was.  So I wrote an application to find out.
>> 
>> I started with the servers currently in the pool from
>> https://sks-keyservers.net/status/
>> 
>> Then queried each active server in turn with /pks/lookup?op=stats
>> 
>> I ended up with the attached diagram.
>> 
>> There were 34 active servers.  The average number of peers per server
>> is 12.  But there are a handful of servers with only 1 or 2 peers.  I
>> did not find any islands.
>> (I ignored the peers with RFC 1918 addresses and servers that did not
>> respond when I made the measurements).
>> 
>> 
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: New peers request

[Todd Fleisher]

Hi Christoph,
Just wanted to check if you were having better luck as I know some people who 
point directly to your server vs. one of the pools and it seems to be returning 
a 502 error currently.

-T

> On Nov 22, 2019, at 12:49 AM, Christoph Martin  wrote:
> 
> Hi Skip,
> 
> Am 21.11.19 um 17:04 schrieb Skip Carter:
>> You can peer with:  keyserver.taygeta.com 11370 #  s...@taygeta.com
>> 
>> I have put you in my access list.
> 
> Thanks.
> 
>> But I must warn you that "Segmentation fault  /usr/sbin/sks db"
>> is a daily occurrence and I have to manually restart it, so at any
>> specific moment it might be down.  Keep trying, you will eventually
>> connect.
> 
> I get a lot of
> 
> HTTP/1.1 503 Service Unavailable
> 
> from your server. I also see the segfaults but my systemd unit is
> restarting it always.
> 
> I am also trying to increase the stacksize via ulimit. The default on my
> system is 8M. I increased to 16M but have still sometimes segfaults. Now
> I am trying 32M.
> 
> Christoph
> 



signature.asc
Description: Message signed with OpenPGP

Re: [Sks-devel] No peers/status?

[Todd Fleisher]

Weird, but I thought it did that to me once too. But after clearing cache & 
cookies I couldn’t reproduce it so I wrote it off. It also doesn’t do that for 
me using curl … so I thought maybe HSTS related, but I don’t see that header 
being sent so I dunno. Maybe the operator is/was making some changes?

-T

> On Sep 30, 2019, at 11:15 AM, Kiss Gabor (Bitman)  wrote:
> 
>> SKS on port 11371 will not have SSL, so the URL should be 
>> http://sks.e-utp.net:11371/pks/lookup?op=stats ? https on port 443 for that 
>> URL does return data: https://sks.e-utp.net/pks/lookup?op=stats 
>> 
> 
> Uhm... HTTP version just redirects me to HTTPS.
> And I guess the same happens with Kristians data harvester.
> 
> Gabor
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] No peers/status?

[Todd Fleisher]

Gabor,
SKS on port 11371 will not have SSL, so the URL should be 
http://sks.e-utp.net:11371/pks/lookup?op=stats … https on port 443 for that URL 
does return data: https://sks.e-utp.net/pks/lookup?op=stats 


-T

> On Sep 30, 2019, at 10:41 AM, Kiss Gabor (Bitman)  wrote:
> 
> Dear Martin,
> 
> According to 
> https://sks-keyservers.net/status/ks-status.php?server=sks.e-utp.net
> sks.e-utp.net has no peers.
> meanwhile at least 4 other servers think peering is established with your one.
> It may not independent from the fact that page
> https://sks.e-utp.net:11371/pks/lookup?op=stats is unreachable with my
> browser:
> 
> An error occurred during a connection to sks.e-utp.net:11371. SSL received a 
> record that exceeded the maximum permissible length. Error code: 
> SSL_ERROR_RX_RECORD_TOO_LONG
> 
> Could you check your setup?
> 
> Cheers
> 
> Gabor
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] ProxMox/Debian 10.1 gnupg2 notice:

[Todd Fleisher]

Nevermind, I was botching the syntax in gpg.conf & also getting mixed up 
between that and dirmngr.conf since GPG Tools calls out that is responsible fro 
key server communication (but not key importing where the stripping happens). 
Thanks again for posting this, Hendrik.

-T

> On Sep 10, 2019, at 10:27 PM, Todd Fleisher  wrote:
> 
> Signed PGP part
> Hendrik,
> Thanks for sharing this. It seems the latest GPG Tools release for macOS 
> integrated the same behavior and is stripping valid 3rd party signatures from 
> newly downloaded or updated keys. I’m trying to work around it, but so far no 
> luck trying to use that option via the command line or in gpg.conf or 
> dirmngr.conf. If anyone has solved for this for that platform please let me 
> know.
> 
> -T
> 
>> On Sep 10, 2019, at 2:03 AM, Hendrik Visage  wrote:
>> 
>> Thought it would be interesting to know this state:
>> 
>> 
>> apt-listchanges: News
>> -
>> 
>> gnupg2 (2.2.12-1+deb10u1) buster; urgency=medium
>> 
>> In this version we adopt GnuPG's upstream approach of making keyserver
>> access default to self-sigs-only.  This defends against receiving
>> flooded OpenPGP certificates.  To revert to the previous behavior (not
>> recommended!), add the following directive to ~/.gnupg/gpg.conf:
>> 
>>   keyserver-options no-self-sigs-only
>> 
>> We also adopt keys.openpgp.org as the default keyserver, since it avoids
>> the associated bandwidth waste of fetching third-party certifications
>> that will not be used.  To revert to the older SKS keyserver network (not
>> recommended!), add the following directive to ~/.gnupg/dirmngr.conf:
>> 
>>   keyserver hkps://hkps.pool.sks-keyservers.net
>> 
>> Note: we do *not* adopt upstream's choice of import-clean for the
>> keyserver default, since it can lead to data loss, see
>> https://dev.gnupg.org/T4628 for more details.
>> 
>> -- Daniel Kahn Gillmor   Wed, 21 Aug 2019 14:53:47 
>> -0400
>> 
>> 
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel 
>> <https://lists.nongnu.org/mailman/listinfo/sks-devel>



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] ProxMox/Debian 10.1 gnupg2 notice:

[Todd Fleisher]

Hendrik,
Thanks for sharing this. It seems the latest GPG Tools release for macOS 
integrated the same behavior and is stripping valid 3rd party signatures from 
newly downloaded or updated keys. I’m trying to work around it, but so far no 
luck trying to use that option via the command line or in gpg.conf or 
dirmngr.conf. If anyone has solved for this for that platform please let me 
know.

-T

> On Sep 10, 2019, at 2:03 AM, Hendrik Visage  wrote:
> 
> Thought it would be interesting to know this state:
> 
> 
> apt-listchanges: News
> -
> 
> gnupg2 (2.2.12-1+deb10u1) buster; urgency=medium
> 
>  In this version we adopt GnuPG's upstream approach of making keyserver
>  access default to self-sigs-only.  This defends against receiving
>  flooded OpenPGP certificates.  To revert to the previous behavior (not
>  recommended!), add the following directive to ~/.gnupg/gpg.conf:
> 
>keyserver-options no-self-sigs-only
> 
>  We also adopt keys.openpgp.org as the default keyserver, since it avoids
>  the associated bandwidth waste of fetching third-party certifications
>  that will not be used.  To revert to the older SKS keyserver network (not
>  recommended!), add the following directive to ~/.gnupg/dirmngr.conf:
> 
>keyserver hkps://hkps.pool.sks-keyservers.net
> 
>  Note: we do *not* adopt upstream's choice of import-clean for the
>  keyserver default, since it can lead to data loss, see
>  https://dev.gnupg.org/T4628 for more details.
> 
> -- Daniel Kahn Gillmor   Wed, 21 Aug 2019 14:53:47 
> -0400
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] New GPGTools release & reliance on SRV records

[Todd Fleisher]

Hi Kristian & other SKS operators,
The team @ GPGTools.Org  released their latest version 
(2019.1) last week on August 22nd. New installations of this release use 
keys.openpgp.org  as the default key server & 
upgrades to this release prompt users to switch. This was known in advanced & 
therefore expected. However, I am noticing another issue that seems to have 
taken hold sometime between release 2018.5 2506n and the current version that 
may require some action on our part to provide continuity for users who are 
upgrading but opting to continue using the SKS key servers.

What I am seeing happen is when attempting to use (or switch back to) an SKS 
key server, the GPGTools clients will claim the server is invalid. Under the 
hood, I can see queries for DNS SRV records being made and returning NXDOMAIN. 
So one of 2 things is required to restore service:

1) DNS SRV records must be published for the hostname in order for GPGTools to 
determine what port number to use:
HKP:
_pgpkey-http._tcp.sks.pod02.fleetstreetops.com has SRV record 0 5 11371 
sks.pod02.fleetstreetops.com.
_pgpkey-http._tcp.sks.pod01.fleetstreetops.com has SRV record 0 5 11371 
sks.pod01.fleetstreetops.com.

HKPS:
_pgpkey-https._tcp.sks.pod01.fleetstreetops.com has SRV record 0 5 443 
sks.pod01.fleetstreetops.com.
_pgpkey-https._tcp.sks.pod02.fleetstreetops.com has SRV record 0 5 443 
sks.pod02.fleetstreetops.com.

2) The port number must be specified in the entry. In the past, 
hkps://hkps.pool.sks-keyservers.net  
worked fine. However, now that same entry appears to be invalid unless I edit 
it to read: hkps://hkps.pool.sks-keyservers.net:443 


I’d advise everyone still in the pool to add the appropriate SRV records & 
especially Kristian as the DNS operator for sks-keyservers.net 
 to do the same for all of the main pool entries.

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] GDPR (equine corpse)

[Todd Fleisher]

> On Aug 17, 2019, at 18:00, Stefan Claas  wrote:
> 
> Todd Fleisher wrote:
> 
>>> On Aug 17, 2019, at 8:46 AM, Stefan Claas >> <mailto:s...@300baud.de>> wrote:
>>> 
>>> Anonymity is a very important point when one likes to communicate securely
>>> and anonymously!
>>> 
>>> For that purpose Anonymous Remailers with a Nym account are in service
>>> for many years. It requires on the users side that he / she is familiar
>>> with GPG, to create a Nym account.
>>> 
>>> http://is-not-my.name/ <http://is-not-my.name/>
>> 
>> This could be considered a bit pedantic … but I would consider a website
>> serving content over unencrypted http and using an invalid SSL certificate
>> for serving https traffic to be neither anonymous nor secure:
>> https://i.imgur.com/drVX1EX.jpg <https://i.imgur.com/drVX1EX.jpg>
> 
> Well, it is only a very old information page. The usage of those Nyms is 
> secure,
> in combination with Mixmaster.
> 
> People not trusting such a service may check out the source code and set-up
> their own Nym Server.
> 
> https://github.com/crooks/nymserv
> 
> There are two more Nym servers available, which I forgot to mention:
> 
> https://remailer.paranoici.org/nym.php
> 
> https://thinhose.net/
> 
> Regards
> Stefan

Thanks for providing these links, I'll have to check them out. I haven't used 
an anonymous remailer since anon.penet.fi went dark over two decades ago 

https://en.m.wikipedia.org/wiki/Penet_remailer

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] GDPR (equine corpse)

[Todd Fleisher]

> On Aug 17, 2019, at 8:46 AM, Stefan Claas  > wrote:
> 
> Anonymity is a very important point when one likes to communicate securely
> and anonymously!
> 
> For that purpose Anonymous Remailers with a Nym account are in service
> for many years. It requires on the users side that he / she is familiar
> with GPG, to create a Nym account.
> 
> http://is-not-my.name/ 

This could be considered a bit pedantic … but I would consider a website 
serving content over unencrypted http and using an invalid SSL certificate for 
serving https traffic to be neither anonymous nor secure: 
https://i.imgur.com/drVX1EX.jpg 

-T

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Todd Fleisher]

> On Aug 16, 2019, at 10:42 AM, Ryan Hunt  wrote:
> 
> Its role as a decentralized, tamper resistant key storage solution is still 
> vital, and I would love it if we had the development going on to address the 
> stability issues, but thats simply not the case at this point in time and 
> until the actual integrity of the data the SKS network serves is compromised 
> there is no need for its death..


I think it would be much more constructive and on topic to this list if we 
could focus on this issue vs. what this thread has devolved into. There are 
very real operational issues with the SKS network and while I don’t agree it 
needs to die, I can attest to the fact that it has become a significant problem 
for some to rely on it for public key distribution because of the poison key 
issue. My key has already been targeted which means the public can no longer 
obtain it from the SKS network and I am not the only person this problem 
impacts.

I am personally not migrating to keys.openpgp.org  
because of the limitations it currently has over the SKS network:

- Cannot perform wildcard searches by domain
- Cannot discover keys that have not been submitted & verified
- Keys lack signatures which breaks the web of trust

I will also point out there is a movement amongst several major software 
distributions that bring PGP support to the masses (especially as it relates to 
email) that are migrating away from the SKS network in large part because of 
this very issue (https://keys.openpgp.org/about/usage 
). And while there are other use cases 
for the SKS network for sure, I believe the ongoing issue where keys can be 
rendered un-importable by malicious third parties without warning threatens its 
very existence and needs to be dealt with before it’s too late.

-T

+cc Kristian directly for higher visibility



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Todd Fleisher]

> On Aug 16, 2019, at 10:24 AM, Stefan Claas  wrote:
> 
> DevPGSV Pablo wrote:
> 
> O.k. I must admit I did not thought about the centralization issue,
> people might have.
> 
> Well, then operators could put that on a link of their own WWW key
> server interface and Kristian could add only a column in his pool
> page, indicating that server x,y,z has a canary, without taking any
> actions.
> 
> Even if Kristian does not like the idea than at least people could
> see that operators are willing to support the idea.

I don’t understand what benefit having operators post warrant canaries is 
supposed to provide in the context of the SKS network.

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Todd Fleisher]

> On Aug 16, 2019, at 10:19 AM, Kiss Gabor (Bitman)  wrote:
> 
>> So to answer your questions:
> 
> Ryan, have you ever seen this funny picture? :)
> http://en.wikipedia.org/wiki/File:DoNotFeedTroll.svg
> 
> Gabor


+1 to this sentiment

If some really want to continue to debate particulars of the GDPR, I’d ask that 
they do it directly and off the list.

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Fwd [from schleuder dev team]: Signature-flooded keys: current situation and mitigation

[Todd Fleisher]

FYI

> Begin forwarded message:
> 
> From: t...@schleuder.org
> Subject: Signature-flooded keys: current situation and mitigation
> Date: July 17, 2019 at 1:07:19 PM PDT
> To: schleuder-annou...@lists.nadir.org
> 
> 
> Dear Schleuder admins and users,
> 
> In the last weeks the SKS keyservers that most people use to find OpenPGP-keys
> have being targeted: many thousand fake signatures were added to some keys and
> then uploaded to the SKS keyserver network.
> 
> GPG does not cope well with these keys. It will either refuse to import them,
> or during and after the import become so slow to be effectively unusable 
> (while
> hogging CPUs). This is a potential problem for Schleuder lists, because
> Schleuder by default regularly updates keys from the keyservers (in order to
> receive extended expiry dates, or key revocations). Any list with an attacked
> key in its keyring will become practically unusable and strain the server.
> 
> To read more details about the SKS keyservers' and GPGs problems see the links
> at the bottom of this mail.
> 
> What to do?
> 
> If you have GPG processes running wild, kill them, identify the attacked key 
> in
> the keyring and delete it. This also will take a lot of time (possibly up to 
> an
> hour) but afterwards GPG will work as expected again. For help with 
> identifying
> the attacked key see https://dev.gnupg.org/T3972#127356.
> 
> Install a Schleuder update when released: We're working on a bugfix release to
> ship a mitigation against these flooded keys: All third-party signatures will
> be removed before a key is imported. These third-party signatures aren't 
> really
> interesting in the context of Schleuder. We will get this released and shipped
> as soon as possible.
> 
> The mitigation will only work for GPG versions 2.1.15 or newer. Please upgrade
> to a more recent GPG version in case yours is older! (Just to give an idea:
> Both Debian stretch and buster are fine in this regard, as well as the CentOS
> packages that are being available.)
> 
> Use a different keyserver: Recently keys.openpgp.org was launched. This
> keyserver does not distribute third-party signatures at all.
> 
> There are downsides to using this server:
> 
> It provides most keys without User-IDs, which GPG (currently) refuses to
> import. Only UserIDs whose owners (validated by email address) opted in to its
> public distribution will be provided, which are (currently) not many. Thus you
> will receive fewer updates from that keyserver.
> 
> X-FETCH-KEY will also not work with UserID-less keys.
> 
> It doesn't distribute key revocations: "Unfortunately, there is currently no
> good way to distribute revocations that doesn't also reveal the revoked
> identity itself. We don't want to distribute revoked identities, so we can't
> distribute the identity at all."
> 
> It is not federated, which makes it a possible "single point of failure".
> 
> Neither of these options is a solution we are really happy with. But we
> currently have nothing better to offer. Please consider yourself what suits
> your setup.
> 
> In case you have any comments, question and/or feedback, please send us an
> email or create a ticket in our issue tracker.
> 
> Cheers,
> the schleuder dev team
> 
> 
> ---
> 
> 
> https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html
> https://dkg.fifthhorseman.net/blog/community-impact-openpgp-cert-flooding.html
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f
> https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e
> https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2019-July/005394.html
> https://blogs.gentoo.org/mgorny/2019/07/04/sks-poisoning-keys-openpgp-org-hagrid-and-other-non-solutions/



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Extreme memory usage

[Todd Fleisher]

To Gabor’s point, I see some similar behavior on my nodes intermittently: 
https://i.imgur.com/aEePr6J.jpg 

It seems to clear up on its own get automatically restarted by systemd after 
OOM kills it so for the most part it doesn’t appear to impact my pool from 
serving requests from the outside, presumably thanks to load balancing and/or 
caching. Also, it does not happen to all nodes at the same time.

FWIW - my nodes do not have the dump directory so that shouldn’t be at play 
here.

-T

> On Jul 17, 2019, at 6:14 PM, Skip Carter  wrote:
> 
> Signed PGP part
> If you do an 'lsof' you will also see all the dump files (223 when I
> built it) are open, even when having done a normal build.  The only way
> to prevent this is to move the dump directory after the build finishes.
> This could also be contributing to the resource consumption.
> 
> On Wed, 2019-07-17 at 19:47 +0200, Kiss Gabor (Bitman) wrote:
>> Dear folks,
>> 
>> I experienced in the past months that my SKS instance dies almost
>> every day.
>> Now I think I found the reason.
>> 
>> Program crashes when e-mail address to be search is broken
>> into mostly 1-3 letter words.
>> These very short words - that are legitim search patters - make
>> sks db process eat the whole 6 GiB RAM of the VM and the OOM killer
>> reapes it.
>> Is this normal? What are your experiences?
>> 
>> Cheers
>> 
>> Gabor
>> 
>> ___
>> Sks-devel mailing list
>> Sks-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/sks-devel
> --
> Dr Everett (Skip) Carter
> s...@taygeta.com
> 
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Todd Fleisher]

SKS logs to syslog, so it gets picked up by log rotate automatically. As for 
the DB itself, make sure you put the sample DB_CONFIG file in place in your 
KDB/DB and PTree directories before you started the SKS DB process to handle 
the DB log files.

-T

> On Jun 23, 2019, at 9:05 AM, Skip Carter  wrote:
> 
> What do you do for log management ?



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] production tweaks

[Todd Fleisher]

> On Jun 17, 2019, at 9:37 AM, Skip Carter  wrote:
> 
> Signed PGP part
> Thanks.  Is there a document describing what can go into sksconf

https://github.com/cmars/sks-keyserver/blob/master/sampleConfig/sksconf.typical 

 has some details & the rest can be found in the man page: 
https://linux.die.net/man/8/sks 




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] The pool is shrinking

[Todd Fleisher]

> On Jun 21, 2019, at 8:00 AM, Skip Carter  wrote:
> 
> Signed PGP part
> As a newcomer to the pool, I have to agree.
> There are several impediments to becoming a keyserver that just
> shouldn't be and the need for daily poking at it is just one of those
> things.  There were several times where I was just ready to give up on
> it.

FWIW - in my experience, once you get things setup & dialed-in there is no need 
for daily poking at it. My load balanced pools have been running for months 
with only the occasional intervention required by me.

> On Jun 21, 2019, at 6:21 AM, Hendrik Visage  wrote:
> 
> The word “cluster” there is the “problem” for hobby setups: we now have to 
> source at least 2x 8GB RAM VMs, where the previous single 2-4GB VMs were 
> sufficient to keep going

I can understand the frustration, but things change and in the current state of 
the SKS network more resources are required. I’d also say the idea of this 
being a “hobby” is in direct opposition to this being a public, production 
service that people rely on which IMO would always dictate at least 3 nodes for 
redundancy.

> On Jun 21, 2019, at 12:33 AM, Kristian Fiskerstrand 
>  wrote:
> 
> 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.

This could mean that people are having less issues with the HKPS pool, but it’s 
also possible there are other reasons for a decrease in complaints. Personally, 
I switched my systems (and the systems of users I support) away from using the 
HKPS pool in favor of using my server(s) due to the ongoing complaints about 
intermittent availability & performance issues in the HKPS pool. That’s not 
meant as a dig on your approach, just letting you know my experience. On the 
contrary, I found you to be quite responsive last September when I reported a 
major issue with 2/3 of the servers in the HKPS pool generating 502 errors.

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Ten thousands new keys

[Todd Fleisher]

Yikes! This probably explains the lag I inquired about in my last email to the 
list.

https://i.imgur.com/Wd77BFF.jpg 

Any insight into the source of the influx?

-T

> On Jun 19, 2019, at 11:24 AM, Kiss Gabor (Bitman)  wrote:
> 
> In the last 3 days some 3 new keys were uploaded.
> The rate is 10 times higher than the average.
> 
> Regards
> 
> Gabor
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Recon lag?

[Todd Fleisher]

Is anyone else noticing lag in the recon process based on the number of keys 
your servers have compared to the max listed @ 
https://sks-keyservers.net/status/ ? I 
graph that for my servers that gossip with the outside world and am noticing a 
much higher delta than I am used to seeing: https://i.imgur.com/laEBLL7.jpg 
. Also, I see the majority of servers in the 
pool reporting high numbers of keys in the delta column. The number found there 
for my servers is even greater than what my graph reports (currently 22,983 on 
the status page vs. peaking just over 6,000 on my graph). I suppose that could 
result from the timing of when my graph queries were run vs. when Kirstian’s 
status page updates.

Is anyone else seeing similar behavior and if so, any ideas what might be 
happening? My first reaction was maybe this is due to my servers having trouble 
syncing with their external peers, but if the same behavior is occurring for 
others with different peers that may not be the case.

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] open files

[Todd Fleisher]

Are you sure you didn’t do a fast build? I originally did a normal build on my 
servers, but due to the initial issues causing me to have to rebuild several 
times I switched to fast build to save time. I am still running that way 
currently and can confirm my sks db process has the dump files opened. The 
documentation claims a normal build will run faster (although it contains an 
odd caveat to that statement - “depending from the source/age of the keydump”), 
but I haven’t noticed any serious performance problems since getting everything 
tuned and dialed in after the first few months. Maybe I will try a re-build one 
of these days and see if there’s any noticeable difference.

-T

> On Jun 18, 2019, at 9:24 AM, Skip Carter  wrote:
> 
> Signed PGP part
> I was doing some maintenance on my sks server and I was surprised to
> see that the sks db process has all of the dump files from the initial
> build open:
> 
> lsof | grep sks
> 
> ks   23189  root   17r  REG  254,35
> 4965717   10747909 /data/sks/dump/sks-dump-.pgp
> sks   23189  root   18r  REG  254,3
> 53884256   10747910 /data/sks/dump/sks-dump-0001.pgp
> sks   23189  root   19r  REG  254,3
> 75707940   10747911 /data/sks/dump/sks-dump-0002.pgp
> sks   23189  root   20r  REG  254,3
> 85833346   10747912 /data/sks/dump/sks-dump-0003.pgp
> sks   23189  root   21r  REG  254,3
> 57206889   10747913 /data/sks/dump/sks-dump-0004.pgp
> sks   23189  root   22r  REG  254,3
> 54697273   10747914 /data/sks/dump/sks-dump-0005.pgp
> and so on...
> 
> I thought that after a normal build that the dump files are no longer used.
> 
> 
> 
> 
> 
> --
> Dr Everett (Skip) Carter
> s...@taygeta.com
> 
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] proxy config

[Todd Fleisher]

Hi Skip,
According to the stats page on your server 
(http://keyserver.taygeta.com:11371/pks/lookup?op=stats 
), you only have 
2250084 keys loaded. Mine shows 5512048, which means you are missing 3261964 
keys which is well above what you should be trying to pull down via recon. 
Please re-build your DB and check the total number of keys is much closer to 
the current number of keys that exist in the pool per the SKS status page 
(https://sks-keyservers.net/status/ ).

-T

> On Jun 6, 2019, at 10:04 AM, Skip Carter  wrote:
> 
> Signed PGP part
> I am finally getting my keyserver running properly.  When building the
> reverse proxy using Apache on Debian, I ran into this error:
> 
> [proxy:warn] [pid 5563:tid 140523378071296] [client
> xxx.xxx.xxx.xxx:2368] AH01144: No protocol handler was valid for the
> URL /pks/lookup. If you are using a DSO version of mod_proxy, make sure
> the proxy submodules are included in the configuration using
> LoadModule.
> 
> The solution is to load the module proxy_http as well as proxy
> 
> This might be worth noting in the documentation
> 
> --
> Dr Everett (Skip) Carter
> s...@taygeta.com
> 
> Taygeta Scientific Inc
> 607 Charles Ave
> Seaside CA 93955
> 831-641-0645 x103
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] understanding error message

[Todd Fleisher]

I’ve never seen those particular errors, but can you share your sksconf & 
membership files to see if there is anything obviously incorrect within? FWIW, 
I cannot query your server @ 
http://keyserver.taygeta.com:11371/pks/lookup?op=stats 
 which would at least 
show the results of the membership file (in theory).

-T

> On Jun 3, 2019, at 6:38 PM, Skip Carter  wrote:
> 
> Signed PGP part
> 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
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] startup troubles

[Todd Fleisher]

Before trying to tackle the issue you are having with the init script, I 
believe you will want to install the latest SKS version 1.1.6 (Release notice: 
https://lists.nongnu.org/archive/html/sks-devel/2016-08/msg0.html 
). You 
may also want to look into installing the package that has a few patches for 
the original, so-called “poison keys” that will almost certainly cause your 
system to be unstable & use much more bandwidth & IO than is necessary. More 
info on that can be found @ 
https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html 
 & 
https://launchpad.net/~canonical-sysadmins/+archive/ubuntu/sks-public/+packages 

 actually has packaged versions with the patch for Ubuntu which may or may not 
work for you out of the box on Debian.

-T

> On May 30, 2019, at 9:33 AM, Skip Carter  wrote:
> 
> 2019-05-30 09:17:27 sks_db, SKS version 1.1.5




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Fulfilled disk

[Todd Fleisher]

Do you have the needed DB_CONFIG files in your DB & PTree directories? This 
used to happen to me before I put those in place an rebuilt my databases. 

Sent from the Fleishphone

> On Mar 28, 2019, at 22:02, Kiss Gabor (Bitman)  wrote:
> 
> Yesterday someone started to fill /var/lib/sks/DB with 1 MiB log files
> until the 40 GiB partition got full:


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] keys.niif.hu is back on the air (Was: Cannot rebuild keys.niif.hu)

[Todd Fleisher]

How much RAM are you (or others) finding is sufficient? I bumped mine up to 8GB 
a while back, but lately even that isn’t enough at times I’ve had my primary 
nodes that gossip with the outside world crash numerous times due out of memory 
errors: https://imgur.com/a/GVJwu4i  & 
https://imgur.com/a/lugDvL7 

-T

> On Mar 26, 2019, at 3:38 AM, Kiss Gabor (Bitman)  wrote:
> 
> Two weeks ago I wrote:
> 
>> Since three weeks keys.niif.hu is out of order.
>> I tried to setup it from scratch. Twice.
>> Keydump is downloaded, database is rebuilt.
>> Program starts but status page shows 0 keys.
>> What did I miss?
> 
> The main problem was lack of enough RAM. Now the VM is reconfigured.
> 
> Gabor
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] hkps and reverse proxy

[Todd Fleisher]

> On Mar 18, 2019, at 9:40 AM, fuat  wrote:
> 
> hkps to be active ServerAlias I need to notify the servers I have
> defined?
> 
> everything works when I do apache proxy settings via static ip.
> however, sks-keyservers.net does not detect the sks that I run on local
> ip with apache when I make proxy from static ip to local ip.

I’m not sure I understand your question. Sounds like you are trying to access 
an apache virtual host over an IP address and are not getting the expected 
content.

> Finally, what is the meaning of these records?
> 
> Error handling request (POST, / pks / add, [
> Accept: * / *
> Content-Length: 82
> content-type: application / x-www-form-urlencoded
> expect: 100-continua
> host: pool.sks-keyservers.net]): Failure ("Error while decoding ascii-
> armored key: text"
> 2019-03-18 19:34:00 Page not found: / pks / lookup / undefined1
>  prompt ('CVE-2014-3207') 

See 
https://bitbucket.org/skskeyserver/sks-keyserver/issues/26/cve-2014-3207-unfiltered-xss
 


-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] hkps and reverse proxy

[Todd Fleisher]

> On Mar 18, 2019, at 11:06 AM, fuat  wrote:
> 
> hkps on my server is running.

That sounds accurate, based on what I am seeing @ https://sks.teknoloji360.com 


> ...
> 
> do I need to add hkps servers to my membership file?

The membership file controls recon and takes place over a specific port outside 
the realm of HKP vs. HKPS. Your membership file should contain a list of 
servers that have agreed to peer with you & their tcp port numbers. Per the 
following excerpt from 
https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering 
 (under Add 
Peers):
Note that the membership lines only provide the SKS recon port; key retrieval 
will happen on a port number one greater than the recon port. Thus recon lines 
are normally on port 11370 and retrieval happens on the normal HKP 11371 port.

-T



signature.asc
Description: Message signed with OpenPGP
___
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

[Todd Fleisher]

Thanks Kristian, looks like it’s resolving now.

-T

> On Mar 18, 2019, at 10:08 AM, Kristian Fiskerstrand 
>  wrote:
> 
> 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.





signature.asc
Description: Message signed with OpenPGP
___
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

[Todd Fleisher]

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/ I’m 
speculating here, but if whatever Kristian users to update the DNS for 
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 
 & 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.

-T

> On Mar 18, 2019, at 8:42 AM, Jim Popovitch  wrote:
> 
> The outage is also mentioned here:
> 
> https://lists.gnupg.org/pipermail/gnupg-users/2019-March/061771.html 
> 


signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] exception Bdb.DBError

[Todd Fleisher]

Improper directory ownership would generate a different fatal error:

Fatal error: exception Bdb.DBError("caml_dbenv_open: open failed.: Permission 
denied”)

-T

> On Mar 13, 2019, at 9:54 AM, Jeremy T. Bouse  
> wrote:
> 
> Signed PGP part
> 
> 
> On 3/13/2019 12:35 PM, fuat wrote:
> > hello, I get the following error.
> >
> > Fatal error: exception Keydb.Unsafe.No_db
> >
> > This error occurred when the gossip was set with the servers.
> > before the apache proxy started giving error. This error occurred
> > after restarting the services. error in the attempt to create a
> > ptree.
> >
> > Fatal error: exception Bdb.DBError ("BDB2506 file key has LSN
> > 226/8900973, past end of log at 1/28")
> >
> > db_recover and db_archive do not output. it didn't work. how to
> > fix this error. thanks.
> >
> 
> That is something I've typically seen if either the /var/lib/sks/DB or
> the /var/lib/sks/PTree directory doesn't exist or it isn't owned with
> permissions that the SKS daemon can access.
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] exception Bdb.DBError

[Todd Fleisher]

If running db_recover doesn’t work, I would recommend re-building your DB from 
an SKS dump.

-T

> On Mar 13, 2019, at 9:35 AM, fuat  wrote:
> 
> hello, I get the following error.
> 
> Fatal error: exception Keydb.Unsafe.No_db
> 
> This error occurred when the gossip was set with the servers. before
> the apache proxy started giving error. This error occurred after
> restarting the services. error in the attempt to create a ptree.
> 
> Fatal error: exception Bdb.DBError ("BDB2506 file key has LSN
> 226/8900973, past end of log at 1/28")
> 
> db_recover and db_archive do not output. it didn't work. how to fix
> this error. thanks.
> 
> --
> ┌--┐
> | Fuat Bölük  fuat[at]teknoloji360[dot]com |
> |--|
> |-- hkps://sks.teknoloji360.com/ --|
> |--|
> | F0D4521D60378B67CE64665EE7C9735903E48A51 |
> └--┘
> --
> I do not know english. I'm using translate.
> --
> 
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] SKS Performance oddity

[Todd Fleisher]

I've been having similar issues his week, though it's mainly high IO load/wait 
that is the issue. Also it's not been my primary nodes that recon with the 
outside world, but some of my secondary nodes that only peer internally. I've 
been restoring them by replacing the DB & PTree files/dirs from another node 
and that seems to do the trick for a period of time but I have already done it 
twice in the last few days so it's not really a sustainable approach. I just 
haven't had time to dig deeper into it to try and determine why it is happening 
and/or how to better protect against it. 

Sent from the Fleishphone

> On Mar 8, 2019, at 19:22, Jeremy T. Bouse  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
>I don't know what is going on here with my cluster but I have 3 of 4
> nodes that absolutely perform as I would expect... They have 2 vCPU
> with 4GB RAM each along with an extra 50GB drive exclusively for SKS
> use under /var/lib/sks. The three behaving fine are my sks02, sks03
> and sks04 secondary nodes. My primary node on the other hand is
> another story. First I tried increasing it from 2 vCPU/4GB RAM like
> the others to 2 vCPU/8GB RAM and then 4 vCPU/8GB RAM without it making
> any change. I then built out a new physical server with a quad-core
> Xeon 2.4GHz processor and 4GB RAM and a dedicated 3TB RAID5 array and
> I'm seeing the same problem. SKS is constantly pegging the CPU at 100%
> and eating up nearly all the memory whether it's running on a virtual
> or physical. server. Recon service is working and I'm ingesting keys
> from peers and peering with my internal cluster nodes but everytime it
> goes into recon mode the node starts failing to respond as the CPU and
> RAM spike which then leads to the node being dropped from the pool as
> the stats page can't be hit before it times out.
> 
>I've been fighting with this for a several days now... Anyone else
> out there seeing this behavior or if not and have similar resourced
> servers care to share details to see if I'm missing something here.
> 
>The particulars are that all nodes are Debian 9.8 (Stretch) 64-bit.
> Then only primary node handles running NGINX configured for load
> balancing the cluster. The only other daemons running across all nodes
> besides SKS are OpenSSH for remote access, SSSD for centralized
> authenication, Haveged for entropy and Postfix configured for
> smarthost relaying.
> -BEGIN PGP SIGNATURE-
> 
> iQGzBAEBCgAdFiEEakJ0F+CHS9VzhSFg6lYpTv4TPXUFAlyDTX0ACgkQ6lYpTv4T
> PXUB0Qv/fRbDkGPes3eq3xDkv6MQHfVFLXuUNdjOtrgpvCwkiS8b340dDKmI5a+x
> NufUzvSHX4GjOc3Joxivc/N1rA7ENrwEX+2T/cwrE8iu+himuvAJkQtXp2qo2Dye
> 9CgzGKR/J0BO50tdmNCJLp6xuR4eY4ISBo0FeeGplipmZIv5BSqKcTcYWaFCNddr
> FLqk6gKT1yzVHb8aO4KzIyB9CqcJEBbTL/RTaJWslCewYcmikw6NBOc1dV/BoxBA
> uGXK3o48o3mo7LJj+sH8/U6F0Ffqnn/tbwIIe/dZSnyonTyP1ENAN2zBWgdzyiRK
> qp1/TDoFC6FuujJgJNKOSsPMNw9bVd5gXYUIIDIE9YK7SeCEP2us4TWS4LQJmuB9
> 7aidQ0rseyN9cSKrswUyWq7k3pM8iLnzx7D8BwW2uvO2SjKo+ALce5UtjyOhgg9v
> ECnxoKjeUTujle/0ZRyi5AbC3AfKi/CoREIJ98w+tAh7jdM5w34vYH8plekRGbFp
> 4bNo9Fyl
> =EdIY
> -END PGP SIGNATURE-
> 
> ___
> 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 scaling configuration

[Todd Fleisher]

Yeah, I thought it looked accurate. Attached is the full config for reference. 
I’m still seeing issues where nginx frequently caches stats data from one of 
the non-primary nodes even when I verify the primary node is responding when I 
query it directly on it’s internal 10-net IP address. It’s puzzling for sure, 
but has taken a back seat to trying to keep my servers stable lately as they’ve 
been experiencing sustained periods of very high IO usage that are causing 
instability. If anyone has nginx configurations to help combat the bad 
key-induced instability, please do share.



nginx.conf
Description: Binary data


-T

> On Mar 5, 2019, at 1:20 AM, Kristian Fiskerstrand 
>  wrote:
> 
> 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: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Debugging a corrupted key

[Todd Fleisher]

If I understand your statement, if you are trying to remove bad data from a key 
that’s already in the network that is not possible. Once it’s in the network 
you can only append new attributes to the key, you cannot remove existing data 
from it. It’s basically a one-way street.

-T

> On Mar 6, 2019, at 1:42 PM, Jim Popovitch  wrote:
> 
> FWIW, I tried, and was unable, to drop and re-upload a clean copy of my key.
> The drop logged as if the key was removed, but a search found the corrupted
> key remained.  I rebuild the DB and my key is presently clean, but I do find
> others (ad...@pgp.pm is one of them)
> 
> -Jim P.




signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] SKS scaling configuration

[Todd Fleisher]

I don’t know if Kristian chose that number based on actual SKS load, since it 
can be hard to predict how much traffic the various servers in the pool may 
receive at any given time. That being said, the rule of 3 is pretty standard in 
operations to prevent a single point of failure from being revealed in the 
event one of your nodes is unavailable.

-T

> On Mar 4, 2019, at 3:18 PM, Jonathon Weiss  wrote:
> 
> Thanks for the information everyone.  A further question:  I saw the advice 
> of a minimum of three servers.  Anyone know how that was arrived at, or if 
> there is a recommendation on how many queries an individual SKS back-end can 
> handle?
> 
>   Jonathon
> 
>   Jonathon Weiss 
>   MIT/IS&T/Cloud Platforms
> 
> 
> 
> 
> On Fri, 1 Mar 2019, Jeremy T. Bouse wrote:
> 
>> I ended up with the following NGINX configuration...
>> in /etc/nginx/conf.d/upstream.conf:
>> upstream sks_secondary {
>> server 127.0.0.1:11371 weight=5;
>> server 172.16.20.52:11371 weight=10;
>> server 172.16.20.53:11371 weight=10;
>> server 172.16.20.54:11371 weight=10;
>> }
>> upstream sks_primary {
>> server 127.0.0.1:11371;
>> server 172.16.20.52:11371 backup;
>> server 172.16.20.53:11371 backup;
>> server 172.16.20.54:11371 backup;
>> }
>> map $arg_op $sks_server {
>> "stats" sks_primary;
>> default sks_secondary;
>> }
>> in /etc/nginx/site-available/sks-default:
>> server {
>> listen 172.16.20.51:80 default_server;
>> listen 172.16.20.51:11371 default_server;
>> listen [::]:80 ipv6only=on default_server;
>> # listen [::]:11371 ipv6only=on default_server;
>> access_log off;
>> server_tokens off;
>> root   /var/www/html;
>> index  index.html index.htm;
>> proxy_buffering on;
>> proxy_buffer_size 1k;
>> proxy_buffers 24 4k;
>> proxy_busy_buffers_size 8k;
>> proxy_max_temp_file_size 2048m;
>> proxy_temp_file_write_size 32k;
>> location /pks/hashquery {
>> proxy_ignore_client_abort on;
>> proxy_pass http://$sks_server;
>> proxy_set_header Host $host;
>> proxy_set_header X-Real-IP $remote_addr;
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> proxy_set_header X-Forwarded-Proto $scheme;
>> proxy_set_header X-Forwarded-Port $server_port;
>> proxy_pass_header Server;
>> add_header Via "1.1 sks.undergrid.net:$server_port (nginx)";
>> }
>> location /pks/add {
>> proxy_ignore_client_abort on;
>> proxy_pass http://$sks_server;
>> proxy_set_header Host $host;
>> proxy_set_header X-Real-IP $remote_addr;
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> proxy_set_header X-Forwarded-Proto $scheme;
>> proxy_set_header X-Forwarded-Port $server_port;
>> proxy_pass_header Server;
>> add_header Via "1.1 sks.undergrid.net:$server_port (nginx)";
>> client_max_body_size 8m;
>> }
>> location /pks {
>> proxy_cache ugns_sks_cache;
>> # proxy_cache_background_update on;
>> proxy_cache_lock on;
>> proxy_cache_min_uses 3;
>> proxy_cache_revalidate on;
>> proxy_cache_use_stale error timeout updating http_500 http_502 
>> http_503 http_504;
>> proxy_cache_valid any 10m;
>> proxy_ignore_client_abort on;
>> proxy_ignore_headers Cache-Control "Expires";
>> proxy_pass http://$sks_server;
>> proxy_set_header Host $host;
>> proxy_set_header X-Real-IP $remote_addr;
>> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>> proxy_set_header X-Forwarded-Proto $scheme;
>> proxy_set_header X-Forwarded-Port $server_port;
>> proxy_pass_header Server;
>> add_header Via "1.1 sks.undergrid.net:$server_port (nginx)";
>> add_header X-Proxy-Cache $upstream_cache_status;
>> }
>> }
>> The NGINX configuration appears to be working fine for me... My 3 backend 
>> nodes are operating as I expect as well.. The problem I'm seeing exhibited 
>> currently is that my primary node which is running along with NGINX seems to 
>> be
>> writing an awful lot of log files and not processing them despite having the 
>> same DB_CONFIG file as the other 3 nodes. With each of the log files running 
>> 100MB 

Re: [Sks-devel] SKS scaling configuration

[Todd Fleisher]

> On Feb 23, 2019, at 8:35 PM, Jeremy T. Bouse  
> 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?

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] seeking peers for keyserver.vanbaak.eu

[Todd Fleisher]

> On Feb 17, 2019, at 11:29 AM, Michiel van Baak  wrote:
> 
> On Sun, Feb 17, 2019 at 10:51:58AM -0800, Todd Fleisher wrote:
>> I see. The resolver I used only showed me your IPV4 addresses. Perhaps a 
>> more seasoned list member can advise if this will work properly as I’ve not 
>> yet come across such a setup. I believe the gossip protocol uses the 
>> hostname value provided on the stats page and am unsure how (or if) it would 
>> work to have the gossip using a different hostname/IP.
> 
> Ok, if that's the case ...
> I have peered with three others now, and I see updates flowing in and
> out.

If it’s working for you it might be fine and I’m just missing or 
misunderstanding something.

> Please let me know if my setup is causing problems.

I’ll have defer to the more seasoned and/or knowledgeable members of the list 
about this.

-T

> --
> Michiel van Baak
> mich...@vanbaak.eu
> GPG key: http://pgp.mit.edu/pks/lookup?op=get&search=0x6FFC75A2679ED069
> 
> NB: I have a new GPG key. Old one revoked and revoked key updated on 
> keyservers.



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] seeking peers for keyserver.vanbaak.eu

[Todd Fleisher]

I see. The resolver I used only showed me your IPV4 addresses. Perhaps a more 
seasoned list member can advise if this will work properly as I’ve not yet come 
across such a setup. I believe the gossip protocol uses the hostname value 
provided on the stats page and am unsure how (or if) it would work to have the 
gossip using a different hostname/IP.

-T

> On Feb 17, 2019, at 10:23 AM, Michiel van Baak  wrote:
> 
> On Sun, Feb 17, 2019 at 09:26:55AM -0800, Todd Fleisher wrote:
>>> On Feb 16, 2019, at 6:19 AM, Michiel van Baak  wrote:
>>> 
>>> I am running SKS version 1.1.6, on keyserver.vanbaak.eu.
>>> The GOSSIP part is running on sks.pgp.vanbaak.eu because of internal
>>> routing and IP policies.
>> 
>> Can you clarify what you are trying to convey here? Both of those hostnames 
>> resolve to the same IP address currently & report:
>> 
>> Hostname: keyserver.vanbaak.eu
> 
> Yes, I can
> 
> My connection is fiber-to-the-home with 1 static ipv4 address and a
> static /48 ipv6 prefix.
> 
> The keyserver.vanbaak.eu and sks.pgp.vanbaak.eu resolve to the same ipv4
> address (the one and only I have) but they resolve to different ipv6
> addresses.
> This, because the vm running nginx has a different address than the one
> running sks.
> Since one can proxy all ports in nginx, except for the GOSSIP protocol,
> I pointed keyserver.vanbaak.eu to my webserver, and sks.pgp.vanbaak.eu
> to the sks server.
> 
> I hope this makes some sense.
> 
> --
> Michiel van Baak
> mich...@vanbaak.eu
> GPG key: http://pgp.mit.edu/pks/lookup?op=get&search=0x6FFC75A2679ED069
> 
> NB: I have a new GPG key. Old one revoked and revoked key updated on 
> keyservers.



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] seeking peers for keyserver.vanbaak.eu

[Todd Fleisher]

> On Feb 16, 2019, at 6:19 AM, Michiel van Baak  wrote:
> 
> I am running SKS version 1.1.6, on keyserver.vanbaak.eu.
> The GOSSIP part is running on sks.pgp.vanbaak.eu because of internal
> routing and IP policies.

Can you clarify what you are trying to convey here? Both of those hostnames 
resolve to the same IP address currently & report:

Hostname: keyserver.vanbaak.eu

-T



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] SKS scaling configuration

[Todd Fleisher]

Hi Jonathon,
I've previously spoken with Kristian about this off-list in an attempt to 
improve the performance & resilience of my own server(s) pool(s), so let me 
share his recommendations which I’ve been using with minimal issues.

The setup uses a caching NGINX server to reduce load on the backend nodes 
running SKS. His recommendation is to run at least 3 SKS instances in the 
backend (I’m running 4). Only one of the backend SKS nodes is configured to 
gossip with the outside world on the WAN, along with the other backend SKS 
nodes on the LAN. The NGINX proxy is configured to prefer that node (the one 
gossiping with the outside world - let’s call it the "primary") for stats 
requests with a much higher weight. As a quick aside, I’ve observed issues in 
my setup where the stats requests are often directed to the other, internal SKS 
backend nodes - presumably due to the the primary node timing out due to higher 
load when gossiping. This then gets cached by the NGINX proxy and continues to 
get served so my stats page reports only the internal gossip peer’s IP address 
vs. all of my external peers. If Kristian or anyone else has ideas on how to 
mitigate/minimize this, please do share. Whenever I check his SKS node @ 
http://keys2.kfwebs.net:11371/pks/lookup?op=stats 
 I always find it reporting 
his primary node eta_sks1 with external & internal peers listed.

Here are the relevant NGINX configuration options. Obviously you need to change 
the server IP addresses & the hostname returned in the headers:

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;
}

upstream sks_servers_primary
{
   server 192.168.0.55:11372 weight=;
   server 192.168.0.61:11371 weight=1;
   server 192.168.0.36:11371 weight=1;
}

map $arg_op $upstream_server {
   "stats" sks_servers_primary;
   default sks_servers;
}


And in server context:

proxy_buffering on;
proxy_buffer_size 1k;
proxy_buffers 24 4k;
proxy_busy_buffers_size 8k;
proxy_max_temp_file_size 2048m;
proxy_temp_file_write_size 32k;

 location /pks/hashquery {
   proxy_pass http://sks_servers/pks/hashquery 
;
   proxy_pass_header  Server;
   add_header Via "1.1 keys2.kfwebs.net ";
   proxy_ignore_client_abort on;
   }

   location /pks/add {
   client_max_body_size 5m;
   proxy_pass http://sks_servers/pks/add 
;
   proxy_pass_header  Server;
   add_header Via "1.1 keys2.kfwebs.net ";
   proxy_ignore_client_abort on;
   }

   location /pks {
   proxy_cache backcache;
   proxy_ignore_headers Cache-Control "Expires";
   proxy_cache_valid any 10m;
  # proxy_cache_bypass $http_cache_control;
   add_header X-Proxy-Cache $upstream_cache_status;
   proxy_pass http://sks_servers/pks ;
   proxy_pass_header  Server;
   add_header Via "1.1 keys2.kfwebs.net ";
   proxy_ignore_client_abort on;
   }


Here is my sksconf file:

#  sksconf -- SKS main configuration
#
#basedir:   /etc/sks

# debuglevel 3 is default (max. debuglevel is 10)
debuglevel: 3

hostname:   sks.pod01.fleetstreetops.com
nodename:   sks03.pod01
hkp_address:127.0.0.1
hkp_port:   11371
recon_port: 11370
#
server_contact: 0xD16C3A41949D203A
#from_addr: pgp-public-k...@example.tld
#sendmail_cmd:  /usr/sbin/sendmail -t -oi
#
initial_stat:
membership_reload_interval: 1
stat_hour:  17
#
# set DB file pagesize as recommended by db_tuner
# pagesize is (n * 512) bytes
# NOTE: These must be set _BEFORE_ [fast]build & pbuild and remain set
# for the life of the database files. To change a value requires recreating
# the database from a dump
#
# KDB/key   65536
pagesize:   128
#
# KDB/keyid 32768
keyid_pagesize: 64
#
# KDB/meta  512
meta_pagesize:  1
# KDB/subkeyid  65536
subkeyid_pagesize:  128
#
# KDB/time  65536
time_pagesize:  128
#
# KDB/tqueue512
tqueue_pagesize:1
#
# KDB/word - db_tuner suggests 512 bytes. This locked the build process
# Better to use a default of 8 (4096 bytes) for now
#word_pagesize: 8
#
# PTree/ptree   4096
ptree_pagesize: 8

disable_mailsync:

# Adding to try and address poison keys
command_timeout: 600
wserver_timeout: 30
max_recover: 150


As for my membership file(s),

Re: [Sks-devel] Annoying malicious keys - any easy solution?

[Todd Fleisher]

Do you (or others) see are any side effects to this approach? I’m particularly 
wondering if it would cause your server to fall behind if it repeatedly closes 
connections from its peers.

-T

> On Feb 17, 2019, at 3:00 AM, Andreas Puls  wrote:
> 
> 
> 
> Am 17.02.2019 um 11:54 schrieb Gabor Kiss:
>>> So, what can I do?
>>> I know ths patch (which seems to be included in debian sks package) to
>>> ignore one special malicious key, but that seems to not help about those
>>> noted above. Is there a patch to add more keys to be ignored?
>>> As some IPs requests the same KeyID over and over again (>100 reqs/day),
>>> I do block those IPs with fail2ban.
>> 
>> Fail2Ban is useful but I intentionally do not log where the requests
>> come. Logging in the proxy is turned off.
>> 
> 
> I'm using nginx as reverse proxy and added this to the config:
> if ( $args ~
> "op=get&options=mr&search=(0x1013D73FECAC918A0A25823986CE877469D2EAD9|0x2016349F5BC6F49340FCCAF99F9169F4B33B4659|0xB33B4659|0x69D2EAD9)"
> ) {
>   return 444;
> }
> 
> 444: Connection Closed Without Response
> 
> Additonal i use fail2ban which triggers on the errorcode 444
>> Gabor
> 
> Br
>  Andreas
>> 
>> ___
>> 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
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Quick and dirty test

[Todd Fleisher]

Correction, the actual URL for the code to generate the visualization is @ 
https://github.com/Timi7007/SKS-Keyserver-Gossip-Network-Graph 
<https://github.com/Timi7007/SKS-Keyserver-Gossip-Network-Graph>

-T

> On Feb 11, 2019, at 4:23 PM, Todd Fleisher  wrote:
> 
> Signed PGP part
> That one does load, but it’s really just a series of directories being 
> cataloged. Once I stumbled across an SVG file, I find the way the data is 
> visualized to be very difficult to digest (e.g. 
> http://sks-status.gwolf.org/20190123-182818/walk_sks_20190123-182818.dot.svg 
> <http://sks-status.gwolf.org/20190123-182818/walk_sks_20190123-182818.dot.svg>)
> 
> I haven’t run it in a while, but https://fleetstreetops.com/gossip/ 
> <https://fleetstreetops.com/gossip/> might be of interest to you. It’s based 
> off the code found @ https://gist.github.com/diafygi/3f344c22f8a37a7b2151 
> <https://gist.github.com/diafygi/3f344c22f8a37a7b2151>
> 
> -T
> 
>> On Feb 7, 2019, at 6:49 AM, Gunnar Wolf > <mailto:gw...@debian.org>> wrote:
>> 
>> Todd Fleisher dijo [Wed, Feb 06, 2019 at 08:24:38PM -0800]:
>>> FYI - that site generates an untrusted ssl certificate warning and
>>> after acknowledging that I get an error that the site couldn't be
>>> found on dreamboat.
>> 
>> You are right, I will now check with Dreamhost why this is
>> happening. Try the same URL, but without SSL:
>> 
>>http://sks-status.gwolf.org/ <http://sks-status.gwolf.org/>
>> 
>> I will soon add some more explanation, the source to my program and
>> more.
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Quick and dirty test

[Todd Fleisher]

That one does load, but it’s really just a series of directories being 
cataloged. Once I stumbled across an SVG file, I find the way the data is 
visualized to be very difficult to digest (e.g. 
http://sks-status.gwolf.org/20190123-182818/walk_sks_20190123-182818.dot.svg 
<http://sks-status.gwolf.org/20190123-182818/walk_sks_20190123-182818.dot.svg>)

I haven’t run it in a while, but https://fleetstreetops.com/gossip/ 
<https://fleetstreetops.com/gossip/> might be of interest to you. It’s based 
off the code found @ https://gist.github.com/diafygi/3f344c22f8a37a7b2151 
<https://gist.github.com/diafygi/3f344c22f8a37a7b2151>

-T

> On Feb 7, 2019, at 6:49 AM, Gunnar Wolf  wrote:
> 
> Todd Fleisher dijo [Wed, Feb 06, 2019 at 08:24:38PM -0800]:
>> FYI - that site generates an untrusted ssl certificate warning and
>> after acknowledging that I get an error that the site couldn't be
>> found on dreamboat.
> 
> You are right, I will now check with Dreamhost why this is
> happening. Try the same URL, but without SSL:
> 
>http://sks-status.gwolf.org/
> 
> I will soon add some more explanation, the source to my program and
> more.
> 



signature.asc
Description: Message signed with OpenPGP
___
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

[Todd Fleisher]

To follow up on this, after making the below changes while my main disk IO went 
down, my load average went up, memory usage went through the roof & swapping 
ensued. I increased the amount of memory assigned to each of my main nodes 
(those that gossip with the outside world) and it seems to be holding steady so 
far: https://imgur.com/a/b0S4Ui2 <https://imgur.com/a/b0S4Ui2>

I believe the nodes may have also been having issues gossiping as I saw 
outbound network traffic flatline during the same time periods: 
https://imgur.com/a/IEoLboM <https://imgur.com/a/IEoLboM>

-T

> On Feb 6, 2019, at 4:21 PM, Todd Fleisher  wrote:
> 
> Signed PGP part
> I also applied these configuration options earlier today to all the servers 
> in 1 of my pools that was experiencing high IO load and repeated SigAlarms:
> command_timeout: 600
> wserver_timeout: 30
> max_recover: 150
> 
> And since then, everything has been quiet:
> 
> IO on the main node that gossips externally: https://i.imgur.com/ERgz0Xo.jpg 
> <https://i.imgur.com/ERgz0Xo.jpg>
> 
> IO from another node in the same pool that gossips internally with the above 
> node: https://i.imgur.com/wsaxrJ5.jpg <https://i.imgur.com/wsaxrJ5.jpg>
> 
> Hopefully this can help other operators keep things in better shape for the 
> time being.
> 
> -T
> 
> 
>> On Feb 6, 2019, at 3:22 AM, Rolf Wuerdemann > <mailto:ro...@digitalis.org>> wrote:
>> 
>> With your suggestions:
>> 
>> load average below 1
>> Traffic: ~150G/day
>> 
>> Best,
>> 
>>   Rolf
>> 
>> Am 2019-02-04 12:52, schrieb Martin Dobrev:
>>> Hi,
>>> I've spent last week trying to optimize configuration as much as
>>> possible. Following advise from a previous mail I've added:
>>>> command_timeout: 600
>>>> wserver_timeout: 30
>>>> max_recover: 150
>>> to my sksconf and it seems this fixed majority of the EventLoop
>>> failures. I've added DB_CONFIG in KDB/PTree folders to get rid of DB
>>> archive logs that were causing plenty of IO load too.
>>> My clusters are now happily responding to queries and load-average is
>>> bellow one. Traffic wise things look better too, ~20GB/day.
>>> Kind regards,
>>> Martin Dobrev
>>> P.S. Adding/changing DB_CONFIG might cause an error in the databases
>>> that you can easily fix by running
>>> db_recover -e -v -h /{KDB,PTree}
>>> On 04/02/2019 09:49, Rolf Wuerdemann wrote:
>>>> Hi,
>>>> Don't get me wrong, but within three days I've got 450G traffic
>>>> which can be assigned to sks by 99.9%. Estimated to 30 days this
>>>> means 4.5T (which is in good agreement of your 2+T/Key for these
>>>> two poison keys).
>>>> With this amount of traffic and the possibility to get
>>>> more of this keys (thus more traffic) every moment, I think it's
>>>> only a question of time until the network with the current
>>>> implementation will vanish. Traffic increased roughly a factor of
>>>> 300 (15G->4.5T) within twelve months, nodes within the network
>>>> decreased by a factor of two at least for the same time.
>>>> So: where to go and how?
>>>> Just my 2ct,
>>>> rowue
>>>> Am 2019-01-30 22:09, schrieb Martin Dobrev:
>>>> Hi,
>>>> My observations so far show that both keys generate  2+ TB/month
>>>> traffic on average for all my clustered nodes. I'm running nginx +
>>>> Varnish in-memory cache tuned at 5 minutes TTL which gives plenty of
>>>> CPU cycles for the never-ending EventLoop alarm loops. The latter
>>>> cause load-average spikes of up to 10 with just 4 Docker containers
>>>> running on a 12 core system.
>>>> Don't get me wrong. The throttling penalty is something I'd
>>>> swallow-up
>>>> as long as we keep the network running.
>>>> Regards,
>>>> Martin
>>>> keyserver.dobrev.eu <http://keyserver.dobrev.eu/> | pgp.dobrev.it 
>>>> <http://pgp.dobrev.it/>
>>>>  Original message 
>>>> From: Kristian Fiskerstrand
>>>> >>> <mailto:kristian.fiskerstr...@sumptuouscapital.com>>
>>>> Date: 30/01/2019 20:18 (GMT+00:00)
>>>> To: Shengjing Zhu mailto:zsj950...@gmail.com>>, 
>>>> sks-devel@nongnu.org <mailto:sks-devel@nongnu.org>
>>>> Subject: Re: [Sks-devel] Unusual traffic for key 0x6

Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.*

[Todd Fleisher]

This sounds like you are missing the recommended DB_CONFIG values to prevent 
your server from holding into those log files when an issue is encountered. As 
I recall, the fix is to start over from scratch and rebuild after first putting 
that file in place. It is covered in the list archives and I believe the source 
and packages ship with an example file that had the needed options. 

Sent from the Fleishphone

> On Feb 6, 2019, at 19:13, Gunnar Wolf  wrote:
> 
> Hello,
> 
> Since a couple of days ago, I have noticed an incredible growth in
> space usage (so much it has killed my server twice, hitting partition
> limits). Since February 3rd, I have over 4000 files with binary-only
> contents (could find no meaningful information in them) called
> /var/lib/sks/DB/log. - I have just
> checked, and it *seems* removing them causes no ill effects.
> 
> But... TTBOMK, I have not modified anything in my configuration. I
> removed them knowing I might be doing something stupid, in the know
> that BDB does not like external processes touching its turf, and was
> happy not to lose my keyserver - but I was ready to rebuild it.
> 
> I haven't been monitoring this list as much as I should. Is there
> anything I should be on the look for? I removed files dated ≤ Feb 3,
> so there is still a lot of information if somebody wants to debug the
> issue.
> 
> Should I just point a "logrotate" or such to the directory? What did I
> do before that I'm not correctly doing now?
> 
> Thanks!
> 
> ___
> 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] Quick and dirty test

[Todd Fleisher]

FYI - that site generates an untrusted ssl certificate warning and after 
acknowledging that I get an error that the site couldn't be found on dreamboat. 

Sent from the Fleishphone

> On Feb 6, 2019, at 19:15, Gunnar Wolf  wrote:
> 
> Kiss Gabor (Bitman) dijo [Tue, Jan 29, 2019 at 07:56:32PM +0100]:
>> Hi folks,
>> 
>> It is funny but one of my peer partners did not notice that his server
>> is dead since a few months. :-)
>> 
>> So I just show anyone who is interested in it how a simple but effective
>> cron job warns me if my server is not OK:
>> 
>> 42 5-8,15-20 * * *   test "$(curl -s 
>> https://sks-keyservers.net/status/ks-status-json.php?server=keys.niif.hu | 
>> jq '[.IPv6, .Port80, .Last_status]' | tee /tmp/sksstatus | md5sum)" = 
>> 'f2a95d496447b4bd81314f4a550a247c  -' || ( echo 'Something went 
>> wrong:\\nhttps://sks-keyservers.net/status/' ; cat /tmp/sksstatus)
>> 
>> Of course hostname and actual MD5 sum value must be tailored
>> according to checked fields of JSON output from curl.
> 
> FWIW, I have been playing with some data that might be connectable to
> this. I did not *yet* intend to go public with this information, but
> it might help use cases as yours:
> 
> https://sks-status.gwolf.org/
> 
> Give me a couple of days and I'll share more complete information. In
> the mean time, you can see where your server is as part of the mesh :-]
> 
> ___
> 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] Unusual traffic for key 0x69D2EAD9 and 0xB33B4659

[Todd Fleisher]

I also applied these configuration options earlier today to all the servers in 
1 of my pools that was experiencing high IO load and repeated SigAlarms:
command_timeout: 600
wserver_timeout: 30
max_recover: 150

And since then, everything has been quiet:

IO on the main node that gossips externally: https://i.imgur.com/ERgz0Xo.jpg 


IO from another node in the same pool that gossips internally with the above 
node: https://i.imgur.com/wsaxrJ5.jpg 

Hopefully this can help other operators keep things in better shape for the 
time being.

-T


> On Feb 6, 2019, at 3:22 AM, Rolf Wuerdemann  wrote:
> 
> With your suggestions:
> 
> load average below 1
> Traffic: ~150G/day
> 
> Best,
> 
>   Rolf
> 
> Am 2019-02-04 12:52, schrieb Martin Dobrev:
>> Hi,
>> I've spent last week trying to optimize configuration as much as
>> possible. Following advise from a previous mail I've added:
>>> command_timeout: 600
>>> wserver_timeout: 30
>>> max_recover: 150
>> to my sksconf and it seems this fixed majority of the EventLoop
>> failures. I've added DB_CONFIG in KDB/PTree folders to get rid of DB
>> archive logs that were causing plenty of IO load too.
>> My clusters are now happily responding to queries and load-average is
>> bellow one. Traffic wise things look better too, ~20GB/day.
>> Kind regards,
>> Martin Dobrev
>> P.S. Adding/changing DB_CONFIG might cause an error in the databases
>> that you can easily fix by running
>> db_recover -e -v -h /{KDB,PTree}
>> On 04/02/2019 09:49, Rolf Wuerdemann wrote:
>>> Hi,
>>> Don't get me wrong, but within three days I've got 450G traffic
>>> which can be assigned to sks by 99.9%. Estimated to 30 days this
>>> means 4.5T (which is in good agreement of your 2+T/Key for these
>>> two poison keys).
>>> With this amount of traffic and the possibility to get
>>> more of this keys (thus more traffic) every moment, I think it's
>>> only a question of time until the network with the current
>>> implementation will vanish. Traffic increased roughly a factor of
>>> 300 (15G->4.5T) within twelve months, nodes within the network
>>> decreased by a factor of two at least for the same time.
>>> So: where to go and how?
>>> Just my 2ct,
>>> rowue
>>> Am 2019-01-30 22:09, schrieb Martin Dobrev:
>>> Hi,
>>> My observations so far show that both keys generate  2+ TB/month
>>> traffic on average for all my clustered nodes. I'm running nginx +
>>> Varnish in-memory cache tuned at 5 minutes TTL which gives plenty of
>>> CPU cycles for the never-ending EventLoop alarm loops. The latter
>>> cause load-average spikes of up to 10 with just 4 Docker containers
>>> running on a 12 core system.
>>> Don't get me wrong. The throttling penalty is something I'd
>>> swallow-up
>>> as long as we keep the network running.
>>> Regards,
>>> Martin
>>> keyserver.dobrev.eu | pgp.dobrev.it
>>>  Original message 
>>> From: Kristian Fiskerstrand
>>> 
>>> Date: 30/01/2019 20:18 (GMT+00:00)
>>> To: Shengjing Zhu , sks-devel@nongnu.org
>>> Subject: 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)
>>> ___
>>> 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
> 
> --
> Security is an illusion - Datasecurity twice
> Rolf Würdemann  -  ro...@digitalis.org  -  DL9ROW
> GnuPG fingerprint:EEDC BEA9 EFEA 54A9 E1A9  2D54 69CC 9F31 6C64 206A
> xmpp: ro...@digitalis.org E1189573 6B4A150C A0C2BF5A 5553F865 0B9CBF7A
>  ro...@jabber.ccc.de 64CBBB68 0A3514A4 026FC1E7 5328CE87 AEE2185F
> 
> ___
> Sks-devel mailing list
> Sks-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/sks-devel



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm always occur with 1 peer

[Todd Fleisher]

Looks like the issue has spread to other peers as the behavior returned when 
reconciling with yet another peer (pgpkeys.co.uk <http://pgpkeys.co.uk/>), so 
I’ve uncommented the previous peer (sks.infcs.de <http://sks.infcs.de/>) and 
will wait for someone to advise if there’s anything that can be done to reduce 
this extra IO load (https://imgur.com/a/wHPYGsK <https://imgur.com/a/wHPYGsK>)

-T

> On Dec 11, 2018, at 10:10 AM, Todd Fleisher  wrote:
> 
> Signed PGP part
> I had gotten things under control after sending this, but starting yesterday 
> it came back when reconciling with a different peer. I commented that peer 
> out for now and things are back to normal.
> 
> Is anyone else seeing similar behavior? Is there anything that can be done 
> other than pausing reconciliation with peers that bring on the issue?
> 
> Here is a graph of my IO during the issue. You can see it drop back to normal 
> immediately after I commented out the problem peer.
> 
> 
> 
> -T
> 
>> On Oct 19, 2018, at 11:38 PM, Paul Fawkesley > <mailto:p...@paulfurley.com>> wrote:
>> 
>> Hi Todd, for what it's worth, I've been experiencing this too since March.
>> 
>> The hangs are so severe my keyserver would fail to respond to requests. In 
>> order not to provide a poor experience to users of the pool, I removed 
>> myself from it.
>> 
>> Anecdotally it appears other keyservers still in the pool are similarly 
>> affected: I experience high rates of timeout and failure when using the pool 
>> these days.
>> 
>> I installed Hockeypuck on another server and peered it with my SKS instance. 
>> It syncs successfully but Hockeypock *also* goes nuts periodically while 
>> syncing. Its memory and CPU use rockets, often pushing into gigabytes of 
>> swap space, so that server is pretty unresponsive too.
>> 
>> I'm about to arrive at the OpenPGP Email summit in Brussels, I'm sure this 
>> will come up as a topic, I shall report back...
>> 
>> Paul
>> 
>> On Wed, 10 Oct 2018, at 19:00, Todd Fleisher wrote:
>>> Hi All,
>>> I wanted to follow up on this and add some new data points. I tried
>>> building some new SKS instances based on a more recent dump
>>> (specifically 2018-10-07 from https://keyserver.mattrude.com/dump/ 
>>> <https://keyserver.mattrude.com/dump/>
>>> <https://keyserver.mattrude.com/dump/ 
>>> <https://keyserver.mattrude.com/dump/>>) and found those instances were
>>> plagued by the same issue when I began peering with my existing
>>> instances. When I re-built the new instances from an older dump
>>> (specifically 2018-10-01 from the same source), the issues went away.
>>> This seems to imply some problematic data was introduced into the pool
>>> during the first week of October that is causing the issues.
>>> 
>>> I found an existing issue logged about this behavior @
>>> https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface
>>>  
>>> <https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface>
>>> <https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface
>>>  
>>> <https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface>>
>>> 
>>> For now, I’m able to keep my instances stable by building them from the
>>> earlier 2018-10-01 dump and not adding the second peer to my membership
>>> file. I would like to better understand why this is happening and figure
>>> out how to go about fixing it, in part so I can begin peering with more
>>> servers to improve the mesh.
>>> 
>>> -T
>>> 
>>>> On Oct 8, 2018, at 1:54 PM, Todd Fleisher >>> <mailto:t...@fleetstreetops.com>> wrote:
>>>> 
>>>> Hi All,
>>>> I recently joined the pool and started having an issue after adding a 
>>>> second external peer to my membership file. The symptoms are abnormally 
>>>> high IO load on the disk whenever my server tries to reconcile with the 
>>>> second peer (149.28.198.86), ending with a failure message "add_keys_merge 
>>>> failed: Eventloop.SigAlarm”. It appears it tries to reconcile a large 
>>>> number of keys (100) consistently when this happens. I’ve read previous 
>>>> list threads about this message (e.g. 
>>>> https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00051.html 
>>

Re: [Sks-devel] sks.daylightpirates.org is staying...again

[Todd Fleisher]

> On Nov 22, 2018, at 2:56 AM, Tobias Mueller  wrote:
> 
> Hi,
> 
> On Wed, 2018-11-21 at 15:42 -0800, Todd Fleisher wrote:
>> onto the public SKS network that many people rely on every day.
> do we have actual numbers here?

An organization I work with has 600+ public keys published to the key servers. 
My total public key count is over 1000 and almost all of them were downloaded 
from the SKS network of key servers.

-T

> Cheers,
>  Tobi



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] sks.daylightpirates.org is staying...again

[Todd Fleisher]

> On Nov 21, 2018, at 12:59 PM, Yegor Timoshenko  
> wrote:
> 
>> Do you happen to have a long-term patch also, or just the
>> hardcoded poison key?
> 
> I don't, and most importantly, I don't think a long-term patch is
> even possible without completely overhauling SKS.

This may be true, but regardless I think we can all agree that a complete 
overhaul is not something that will just happen overnight. Furthermore, the SKS 
network of key servers is currently the best (and maybe only) game in town for 
mass public distribution of GPG keys so I think I speak for many people when I 
say let’s try to avoid introducing any more issues that could (and in my 
opinion should) be handled in isolated and controlled test environments vs. the 
actual network.

> The first and more prominent one is
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/41, lack
> of validation, closed as WONTFIX. That is also a critical UI flaw
> that makes it easy to trick users who use HTTP interface.

I agree this issue (authenticity of data found on the key servers) is one many 
would like to see solved, but also agree it’s not what the SKS key server pool 
was designed for. Maybe SKS can be adapted to solve this problem or maybe it 
will require a new technology. Personally, I’ve solved for this issue on the 
client side by automating keyring management to some extent by checking for 
specific authority signatures (per domain) on keys found on the SKS network and 
then only import those that I deem “authentic". I know Micah (who reported that 
issue) has done something similar with GPGSync: 
https://github.com/firstlookmedia/gpgsync 


>> It is very easy to test for vulnerabilities if you actually
>> install sks on your own machine first, and try to also fix it
>> before publishing/exploiting it. Many have tutorials on this
>> subject and all you need is a copy of a key dump.
> 
> Not really. This particular key poison vulnerability can only be
> seen if you have a testing network of at least three keyservers.

Those two sentences appear to be in opposition of each other. It would have 
just required more effort on the part of the tester to setup at least 3 key 
servers to test with.

> I didn't know the extent of damage my attacks will have: I was
> just poking SKS for basic attack vectors that, at that time, I
> was sure would have no effect at the network at large. I haven't
> looked at SKS source code while testing any of the attacks
> whatsoever.

That first sentence really irks me. I personally would appreciate future 
testers taking heed of a proper testing approach vs. unleashing code/data 
containing unknown and/or unpredictable results onto the public SKS network 
that many people rely on every day.

> I didn't even know these attacks had any pronounced long-term
> effect on the network before ~3 weeks ago when I took a look at
> sks-devel@ mailing list and found a huge discussion on the topic.
> (I was never approached about this until recently.)

Not to beat a dead horse, but therein lies the problem. If you didn’t know what 
the impact would be, I feel you should not have injected test data into the SKS 
network without first doing due diligence in an isolated test environment.

> Historically speaking, it would seem as if benevolently attacking
> the network was the most effective way to have it evolve. Say,
> consider Evil 32, which was an effort that included bruteforcing
> a 32-bit fingerprint lookalike to every key in trusted set
> (https://evil32.com) and uploading it to keyservers. By then, the
> danger of 32-bit key fingerprints was known for a long time, but
> no one did anything about it.

And while that could cause problems for folks using the trusted set of GPG keys 
and 32-bit fingerprints … I don’t think it caused instability in the SKS 
network by way of increasing usage of server & network resources - neither of 
which are “free" for everyone - nor did it compromise nodes on the network when 
they crashed as a result of the bogus keys being uploaded.

>> There are other ways of bringing an sks server down, and BDB
>> might not be the best idea for a server, still the network is
>> important for both free software and individuals using it.
> 
> There are likely other low-effort ways of bringing an SKS server
> down :-(
> 
> You are right that SKS network is still important to a lot of
> people, however I believe that this trust has been misplaced.
> Hopefully these attack vectors (and potential mitigations) being
> public will bring awareness to the issue and motivate someone to
> create a more robust alternative to SKS, and users to prefer less
> exploitable ways to share keys (or choose a different encryption
> scheme entirely, say one that has forward secrecy, or pursue more
> contained tools for signatures such as OpenBSD signify(1) or
> minisign).

I believe the importance of the SKS network to people is mutually exclusive of 
whether or not said peop

[Sks-devel] Replacing sks01.pod01.fleetstreetops.com & sks02.pod01.fleetstreetops.com with load balanced setups

[Todd Fleisher]

Hi,
I am in the process of migrating my external peers from 
sks01.pod01.fleetstreetops.com <http://sks01.pod01.fleetstreetops.com/> & 
sks02.pod01.fleetstreetops.com <http://sks02.pod01.fleetstreetops.com/> to 
sks.pod01.fleetstreetops.com <http://sks.pod01.fleetstreetops.com/> & 
sks.pod02.fleetstreetops.com <http://sks.pod02.fleetstreetops.com/>. I have 
reached out to operators of the servers currently peering with those hosts to 
update their membership files accordingly. This message is meant to serve as a 
public notice of the change. I will send a final notice when I fold the 2 older 
hostnames into the load balanced pools.

If others are interested in peering with me, below are the lines to add to your 
membership files:

sks.pod01.fleetstreetops.com 11370 # Todd Fleisher  
0x030C8D58A26E7D1264044A0BD16C3A41949D203A

sks.pod02.fleetstreetops.com 11370 # Todd Fleisher  
0x030C8D58A26E7D1264044A0BD16C3A41949D203A

For operational issues or if you would like to peer, please contact me directly.

-T

> On Oct 2, 2018, at 10:00 AM, Todd Fleisher  wrote:
> 
> Signed PGP part
> Hi,
> I am looking for peers for a new SKS keyserver installation.
> 
> I am running SKS version 1.1.6, on sks01.pod01.fleetstreetops.com & 
> sks02.pod01.fleetstreetops.com
> 
> The servers are physically located in California (US).
> 
> The machines do not currently have IPv6 connectivity.
> 
> I have loaded a keydump from https://keyserver.mattrude.com/dump/, dated 
> 2018-10-01. I see 5333430 keys loaded.
> 
> For operational issues, please contact me directly.
> 
> sks01.pod01.fleetstreetops.com 11370 # Todd Fleisher 
>  0x030C8D58A26E7D1264044A0BD16C3A41949D203A
> 
> Thanks,
> Todd Fleisher
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm always occur with 1 peer

[Todd Fleisher]

Hi All,
I wanted to follow up on this and add some new data points. I tried building 
some new SKS instances based on a more recent dump (specifically 2018-10-07 
from https://keyserver.mattrude.com/dump/ 
<https://keyserver.mattrude.com/dump/>) and found those instances were plagued 
by the same issue when I began peering with my existing instances. When I 
re-built the new instances from an older dump (specifically 2018-10-01 from the 
same source), the issues went away. This seems to imply some problematic data 
was introduced into the pool during the first week of October that is causing 
the issues.

I found an existing issue logged about this behavior @ 
https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface
 
<https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface>

For now, I’m able to keep my instances stable by building them from the earlier 
2018-10-01 dump and not adding the second peer to my membership file. I would 
like to better understand why this is happening and figure out how to go about 
fixing it, in part so I can begin peering with more servers to improve the mesh.

-T

> On Oct 8, 2018, at 1:54 PM, Todd Fleisher  wrote:
> 
> Hi All,
> I recently joined the pool and started having an issue after adding a second 
> external peer to my membership file. The symptoms are abnormally high IO load 
> on the disk whenever my server tries to reconcile with the second peer 
> (149.28.198.86), ending with a failure message "add_keys_merge failed: 
> Eventloop.SigAlarm”. It appears it tries to reconcile a large number of keys 
> (100) consistently when this happens. I’ve read previous list threads about 
> this message (e.g. 
> https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00051.html 
> <https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00051.html> & 
> https://lists.nongnu.org/archive/html/sks-devel/2011-06/msg00077.html 
> <https://lists.nongnu.org/archive/html/sks-devel/2011-06/msg00077.html>) 
> which mention the cause potentially being a large key trying to be processed 
> and failing. I tried increasing my client_max_body_size from 8m -> 32m in 
> NGINX, but the issue persisted. For now, I have removed the second peer from 
> my membership file to keep from over-taxing my server with no apparent 
> benefits. I have included an excerpt of my logs showing the behavior. Can 
> someone please advise what might be causing this issue and what can be done 
> to resolve it? Thanks in advance.
> 
> 
> 
> -T
> 



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm always occur with 1 peer

[Todd Fleisher]

Hi All,I recently joined the pool and started having an issue after adding a second external peer to my membership file. The symptoms are abnormally high IO load on the disk whenever my server tries to reconcile with the second peer (149.28.198.86), ending with a failure message "add_keys_merge failed: Eventloop.SigAlarm”. It appears it tries to reconcile a large number of keys (100) consistently when this happens. I’ve read previous list threads about this message (e.g. https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00051.html & https://lists.nongnu.org/archive/html/sks-devel/2011-06/msg00077.html) which mention the cause potentially being a large key trying to be processed and failing. I tried increasing my client_max_body_size from 8m -> 32m in NGINX, but the issue persisted. For now, I have removed the second peer from my membership file to keep from over-taxing my server with no apparent benefits. I have included an excerpt of my logs showing the behavior. Can someone please advise what might be causing this issue and what can be done to resolve it? Thanks in advance.Oct  6 21:37:38 sks01 sks[21271]: 2018-10-06 21:37:38 45 hashes recovered from 

Oct  6 21:37:38 sks01 sks[21270]: 2018-10-06 21:37:38 100 keys found
Oct  6 21:37:48 sks01 sks[21271]: 2018-10-06 21:37:48 Requesting 45 missing 
keys from , starting with 
01870661E19C1AC64A9B2202C39C703E
Oct  6 21:38:41 sks01 sks[21271]: 2018-10-06 21:38:41 45 keys received
Oct  6 21:38:41 sks01 sks[21271]: 2018-10-06 21:38:41 Reconciliation attempt 
from  while gossip disabled. Ignoring.
Oct  6 21:39:21 sks01 sks[21270]: 2018-10-06 21:39:21 Applying 0 changes
Oct  6 21:40:48 sks01 sks[21271]: 2018-10-06 21:40:48 38 hashes recovered from 

Oct  6 21:40:49 sks01 sks[21271]: 2018-10-06 21:40:49 Requesting 38 missing 
keys from , starting with 
018B98ED63D0F70F961626FC74458EE7
Oct  6 21:40:49 sks01 sks[21271]: 2018-10-06 21:40:49 38 keys received
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Applying 59 changes
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
018B98ED63D0F70F961626FC74458EE7
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
14DD4E8E5CF075C7584027D39E24A9D7
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
17EA3D31D3414E033B9CBFBA20006BD9
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
19823BED51BB729E9389D154BAD747E0
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
199D6FFDA7DC86105C18AA01F30BD221
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
19F3EAF1E63CE1D57E829BC451B38114
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
22AD2A65D86B02AD93C9012CBCEAAA1B
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
22EE1BB8B97FE9B5D8466DB6402F80CA
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
2309DD6AF2606DDCD801307FAC024E28
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
231CE216CD76FD3F9797C7BDD4ACA541
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
2B95D6117C2F01CE8A665CC35FF4A43B
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
2C8D6E840ACD289AB7B8337F206FC8FD
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
2DE31F0D6A64BBD17DEC51418BF35E98
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
3BDB66C9A7EB384EC445D724FD80FCB7
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
3E13EA8D80E47F67B88E987592FFD914
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
3ECDFF2A1DF947E6DF8863EACF1C9517
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
50E685D9658E3010782C635D07DCA327
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
523E22974916AB8C9FF5410B39C5300E
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
54E975819169BA49C800B719ADC56F17
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
5699F92E6316448E43FB6D18C6F0943F
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
57AA5ACD8CEA0EC6397F73CD71A31026
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
5907B34EA6FD1F52FE8A20485D9E847C
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
5C3912C041B3AD7EFB47221ACFE47B8B
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
68F0B680A619A28F950679A0426FE3B1
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
6AD7D6CA26FC98A475834AEEDDACBEDE
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
6BB08E6E90501636EEB723310EBA741A
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
6C7D69C8D90F8EE83E49C0EEC98D7224
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Del'ng hash 
7889FBB3A0A489684600A905A314442C
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
8A827C7FC66C871E939DA1C3697C58C0
Oct  6 21:41:37 sks01 sks[21270]: 2018-10-06 21:41:37 Adding hash 
8E6B528591D2100C0F86

[Sks-devel] seeking peers for sks01.pod01.fleetstreetops.com

[Todd Fleisher]

Hi,
I am looking for peers for a new SKS keyserver installation.

I am running SKS version 1.1.6, on sks01.pod01.fleetstreetops.com & 
sks02.pod01.fleetstreetops.com

The servers are physically located in California (US).

The machines do not currently have IPv6 connectivity.

I have loaded a keydump from https://keyserver.mattrude.com/dump/, dated 
2018-10-01. I see 5333430 keys loaded.

For operational issues, please contact me directly.

sks01.pod01.fleetstreetops.com 11370 # Todd Fleisher  
0x030C8D58A26E7D1264044A0BD16C3A41949D203A

Thanks,
Todd Fleisher



signature.asc
Description: Message signed with OpenPGP
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel