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
