Hockeypuck 2.2 released

[Andrew Gallagher]

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:

# Features

• Fully stable sync (https://github.com/hockeypuck/hockeypuck/issues/198)
• Improved multithreading safety 
(https://github.com/hockeypuck/hockeypuck/issues/170)
• Deletion of personal data from hard-revoked keys 
(https://github.com/hockeypuck/hockeypuck/issues/250)
• Admin deletion of keys via signed submissions 
(https://hockeypuck.io/admin.html)
• Detached revocation certificate support 
(https://github.com/hockeypuck/hockeypuck/issues/281)

# Bugfixes

• Missing direct key signature validation 
(https://github.com/hockeypuck/hockeypuck/issues/199)
• Missing subkeys with v3 sbinds 
(https://github.com/hockeypuck/hockeypuck/issues/205)
• Missing CORS headers (https://github.com/hockeypuck/hockeypuck/issues/226)
• HTTPS binding errors (https://github.com/hockeypuck/hockeypuck/issues/295)
• Many cosmetic improvements 
(https://github.com/hockeypuck/hockeypuck/issues/257https://github.com/hockeypuck/hockeypuck/issues/289
 https://github.com/hockeypuck/hockeypuck/issues/291 …)

# Deprecations

• SKS-keyserver recon compatibility
• UAT image packets
• User deletion and replacement of keys via `/pks/delete` and `/pks/replace` 
endpoints (https://github.com/hockeypuck/hockeypuck/issues/136)

Dropping sks-keyserver backwards compatibility gets rid of several long-running 
sync issues. Hockeypuck validates self-sigs but sks-keyserver does not, and 
maintaining sync consistency with sks-keyserver means storing and propagating 
obsolete and broken packets, which has never worked reliably. We believe this 
is the root cause of the “key churn” issues experienced by keyserver operators 
in recent years.

Dropping support for UAT images reduces the storage footprint of a keyserver, 
and eliminates an obvious abuse vector.

The `/pks/delete` and `/pks/replace` endpoints for end-user control have 
several weaknesses and are now deprecated. They are still available for use by 
operators (with a slightly modified protocol, see 
https://hockeypuck.io/admin.html).

User control of their own keys will in future be primarily handled via 
self-signatures and self-revocations (“self-sovereignty”). Hard revocation of a 
key (e.g. by publishing the revocation certificate saved at key generation 
time) causes all User IDs attached to that key to be deleted. This allows key 
owners to automatically remove their personal information from the entire 
keyserver network. Further self-sovereignty features are planned for upcoming 
releases (e.g. 
https://github.com/hockeypuck/hockeypuck/wiki/HIP-3:-Timestamp-aware-merge-strategy).

# Installation and upgrading

You can install hockeypuck by cloning the repo from 
https://github.com/hockeypuck/hockeypuck and checking out the tag `2.2`, then 
following the instructions in the `README.md` file. If you wish to track future 
patch releases, you should instead check out the branch `branch-2.2`. You 
should not deploy from the master branch in production.

BEWARE that while it is possible to upgrade from 2.1 to 2.2 in-place, it is 
RECOMMENDED to dump and restore into a clean install. This is because version 
2.2 has stricter key validation policies (see below) and the best way to ensure 
your database is fully updated is to reload from a fresh dump. An in-place 
upgraded hockeypuck will eventually sync with its peers, but the process is 
inefficient due to the large number of changes involved.

More information can be found at the hockeypuck wiki: 
https://github.com/hockeypuck/hockeypuck/wiki

Thanks,
Andrew

signature.asc
Description: Message signed with OpenPGP