sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Keyserver] Hockeypuck 2.1.0 released


From: Casey Marshall
Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
Date: Thu, 10 Dec 2020 14:33:22 -0600

On Thu, Dec 10, 2020 at 1:45 PM Dan Egli <dan@newideatest.site> wrote:

Interesting. But how does Hockeypuck's feature list compare to SKS? For example, does it exchange keys with other servers in the same manner as SKS (i.e. via a recon/"gossip" method)? Does it have a good web front end included?

Hockeypuck implements the HTTP Keyserver Protocol (HKP) as well as the SKS reconciliation protocol. The web front end is fairly minimal and not really a priority; I consider keyservers to be backend infrastructure. My main focus is on supporting operations around distributing software package signing keys.

You're posting this on a list for people who already use the SKS system. I hope you're not going to just announce a competitor product and run away.

If there's a better forum for things of interest to keyserver operators, happy to post future updates there instead and sorry for the noise.

This latest release adds some new content blocking features that I believe are effective and may be of general interest to keyserver developers and operators. Mitigating the flood of hostile content uploaded to keyservers is in our common interest, and I thought it might be good to share how I'm addressing it in Hockeypuck.

On 12/10/2020 10:07 AM, Casey Marshall wrote:

I've released Hockeypuck 2.1.0 [0], which contains several new features that may be useful to mitigate spamming/flooding/DoS [1] attacks on GnuPG and keyservers. See the release link for details, but here's the highlights:

  • Configurable key length and packet size limits, with sensible defaults to limit keyserver resource consumption (1MB and 8K respectively).
  • Configurable blacklist of primary key fingerprints.
  • Authenticated key management. This adds a couple of extra endpoints which allow a key owner to replace and delete their key, authenticated by signing the armored key in the request. This allows a key owner to still update their own key once it has been inflated beyond the key length limit.

Blacklists and auth key management may also be of interest to keyserver operators subject to GDPR-related requests.


-Casey


[0] https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0

[1] https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

-- 
Dan Egli
>From my Test Server

reply via email to

[Prev in Thread] Current Thread [Next in Thread]