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 from https://github.com/hockeypuck/hockeypuck and checking out the tag “2.2.1”. If you wish to track future patch releases, you should instead check out the branch `branch-2.2`. It is not recommended to deploy from the `master` branch in production. PLEASE NOTE that while it is possible to upgrade from 2.1.x to 2.2.x in-place, it is RECOMMENDED to dump and restore into a clean install. This is because version 2.2.x has stricter key validation policies 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. Patch updates, such as from 2.2 to 2.2.1, can always be performed in-place without issue. You can find more information at the hockeypuck wiki here: https://github.com/hockeypuck/hockeypuck/wiki Thanks, Andrew. > On 22 May 2024, at 18:42, Andrew Gallagher <andr...@andrewg.com> wrote: > > 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
