Re: keyserver.insect.com GDRP takedown request

Thank you for the procedure. For this specific user, he was helpful enough to include the keyids, so it is somewhat easier: - Run the following command to get the keyIds for the blacklist to add:cat < fingerprints.txt | tr A-Z a-z | sed -e "s/^/'/" -e 's/$'"/'/" | tr \\012 ,; echo - Add them

Re: State of the graph

Andrew, thanks for the visualization! I'm feeling flattered that keyserver.trifence.ch is at the center of the graph, but this also means it could become a single point of failure (and currently, sks.pyro.eu.org is trying to get back up to speed and has probably requested ~80k keys in past few

Re: hockeypuck runaway

Skip, I noticed a similar error message, but just with one of my peers about a week ago. I did not notice an extremely high load, though (maybe just didn't watch closely enough?). I had looked at some of the read length numbers, then, looking for a potential source of the problem. Here's what I

Re: HockeyPuck deployment problems

Michele, it is great to hear about your interest in computer security and I am sorry to hear that you do have problems with Hockeypuck in Docker. I am running two Hockeypucks under Docker and have had some problems in the beginning, but I hoped that what I learned during that process had been

Re: High rate of updated keys

I have not investigated closely, but I noticed that after a restart of the Hockeypuck server, several hundred "updates" are being processed (I am using the version which does negative caching of recon attempts which did not result in updates). So, maybe we need to look closer at what actually

Re: Key diff anomaly

Gabor, all, the numbers are positive again, but the anomaly still persists (UTwente 73k ahead of the active keyservers). It seems that from the active set, only Andreas Puls and escomposlinux are being peered with. I hope the operators of these three nodes can have a look at their peering and the

Re: Pool dried up

> > > > > > Looking at the cached metadata it appears that when the spider > > > > ran, > > > > pod02.fleetstreetops nodes was unavailable, as was > > > > pgpkeys.co.uk > > > Apologies, I didn't mean to cast doubt on the reliability of your > > node, > > but rather on that of the spider. It does

Re: Lying about Hockeypuck being SKS?

inc.php;h=972bb5b56412ae54b8aade234ea02bb8c9545d45;hb=HEAD#l309 On Mon, 2021-03-22 at 21:13 +0100, Andreas Puls wrote: > > > Am 22.03.2021 um 20:41 schrieb Marcel Waldvogel: > > On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote: > > > > > > I've crea

Re: An evil idea :-)

Gabor, so, please call me Mr. Evil ;-) A few weeks ago, I set up a simple Nginx load balancer (two lines with https-portal[1]) statically seeded with the nodes that were in the pool at that time for test purposes. It randomly returns the status page of one of the backend servers, though, but

Lying about Hockeypuck being SKS?

On Sun, 2021-03-21 at 22:56 +0100, Andreas Puls wrote: > > I've created now a patch that just replaces in the json export > contact > with server_contact and Total with numkeys. > https://github.com/apuls/hockeypuck/commit/34fbdfcf73b60e6001f3770b86d8750d1c8b5385 Great, thanks! I just merged

Seeking peers for keyserver.trifence.ch

with: keywin.trifence.ch 11370 # Marcel Waldvogel 0x9CF85070DD5B7293B6988379C3C53A69327FB3DC while Hockeypuck servers should peer with: # Marcel Waldvogel # 0x9CF85070DD5B7293B6988379C3C53A69327FB3DC [hockeypuck.conflux.recon.partner.hkp-winterthur] httpAddr="keyserver.trifence.ch: