Hockeypuck 2.2.1 released

Hi, all. We are pleased to announce the release of Hockeypuck version 2.2.1. This is a bugfix release that addresses two issues with the machine-readable HKP index format that may result in incomplete information being returned to clients. You can install the latest release by cloning the repo

Hockeypuck 2.2 released

We are pleased to announce the release of Hockeypuck 2.2. Hockeypuck is a modern synchronising keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose. Hockeypuck 2.2 is a significant upgrade that includes the following changes: #

Re: Seeking peers for keys.dryusdan.net

On 5 Apr 2024, at 18:36, Dryusdan wrote: > > I double check and no, HAP_BEHIND_PROXY wasn't set. But > HAP_BEHIND_PROXY_EXCEPT_HKP is (in /etc/default/haproxy I directly set > variable and it loaded by systemd service) > > Is now ok :) > So that would imply that ports 80 and 443 are behind

Re: Seeking peers for keys.dryusdan.net

On 5 Apr 2024, at 17:34, Dryusdan wrote: > > I change my setup today and add HAProxy and standalone configuration. > Actually it is behind nginx for both, keys.dryusdan.net > and gpg.4n0ny.me . Great stuff! Did you make sure to uncomment

Re: Seeking peers for keys.dryusdan.net

On 31 Mar 2024, at 21:25, William Hay wrote: >> > Do you have protections against flooding attacks in place on your > keyservers(appropriately > configured rate limiting proxy)? Hi, guys. According to the spider at https://spider.pgpkeys.eu/sks-peers, keys.dryusdan.net and gpg.4n0ny.me

Hockeypuck 2.2

Hi, all. I have a stable development branch for Hockeypuck 2.2 that is ready for beta testing. If anyone wants to help test, please pull the latest branch at https://github.com/pgpkeys-eu/hockeypuck/tree/branch-2.2.0 onto a test machine, and restore from a fresh dump (this is important). For

Re: Key server status

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

Re: Seeking Peers

On 23 Jan 2024, at 20:38, Gerald Stueve wrote: > > On Tue, 2024-01-23 at 18:35 +, Andrew Gallagher wrote: >> >> I can see it now! It’s reporting version 1.1.6 though, have you overridden >> it in the hockeypuck.conf file? I’d recommend against doing that - it used >> to be necessary when

Re: Seeking Peers

On 23 Jan 2024, at 02:35, Gerald Stueve wrote: > Please try again, it appears accessible from outside my local > network > hockeypuck 2.1.2 > 6613215 keys from pgp.cyberbits.eu last week I can see it now! It’s reporting version 1.1.6 though, have you overridden it in the hockeypuck.conf file?

Re: Seeking Peers

On 18 Jan 2024, at 01:57, Gerald Stueve via SKS development and deployment list wrote: > > I am finally replacing my old sks keyserver keys.stueve.us with a > hockeypuck based system and would appreciate any peers. > > [hockeypuck.conflux.recon.partner.keys_stueve_us] > #

Re: Flooding attack against synchronising keyservers

Hi, all. pgpkeys.eu is fully operational, is accepting key submissions and is syncing with two similarly recovered peers. The number of keys in the dataset is back to pre-flooding levels, and site reliability has been significantly improved. If you are an operator and need assistance

Flooding attack against synchronising keyservers

Hi, everyone. The synchronising keyserver network has been under an intermittent flooding attack for the past five days, resulting in the addition of approximately 3 million obviously-fake OpenPGP keys to the SKS dataset. The fake keys are currently being submitted multiple times per second

Some proposals for future synchronising keyserver development

Hi, all. It’s been quiet in keyserver land recently, but I recently published four proposals for how to move forward on the Hockeypuck github blog, and all feedback is welcome: HIP 2: SKS v2 protocol Sync using hashes of self-sig packets rather than hashes of TPKs would mitigate