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
