New Blog: #Keyserver Updates and Roadmap, December 2025

...

About half of the public #Hockeypuck keyservers have been upgraded to the 2.3 branch (as of 2025-12-08), including the pgpkeys.eu servers. A small number remain on 2.1 for compatibility reasons, but the remaining issues preventing upgrade of these 2.1 servers will be addressed in an upcoming 2.3.x release.

...

While HKPv2 and RFC9580 support are the current priorities, further improvements are planned for delivery in 2026 and 2027. These include:

* Allowing #OpenPGP key owners to explicitly restrict the distribution of third-party signatures over their User IDs, to prevent signature flooding.
* Out of band email proofs of User ID validity, to mitigate spam and impersonation.
* A fully-featured management API to better handle deletion and blocklisting of incorrect or spammy keys.
* Native rate limiting and tor exit node abuse detection.
* Detection (and potential removal) of keys with known vulnerabilities or weaknesses.
* Improvements to the dump and restore process to allow a running server to be backed up without a restart.

https://blog.pgpkeys.eu/keyserver-roadmap-2025-12.html

#infosec #cryptography #pgp

News from the coalface!

The pgpkeys.eu test swarm is now running an alpha version of #hockeypuck 2.3, and is gradually reindexing itself to populate the new SQL table structure required for RFC9580 and PQC support.

The PostgreSQL storage layer has been extensively refactored and improved. It now supports background reindexing during normal operation, and in-place reloading of the database without dumping to disk. Previously, reindexing and reloading were only possible by dumping, deleting the database, and reloading the dump from scratch, which was an error-prone manual process - in v2.3 reloading will be a single command, and reindexing happens automagically. 🤩

Old-school PKS sync has also been implemented natively, to enable (less efficient, more robust) sync between different versions of Hockeypuck, or even with non-SKS keyservers such as Hagrid 😈.

These changes will make it much easier for #keyserver operators to upgrade to newer versions of hockeypuck, and increase the reliability of the synchronising keyserver network.

Watch this space for more news, particularly about the upcoming support for PQC algorithms in #openpgp!

(Hockeypuck 2.3 development is generously supported by @NGIZero)

News from the coalface:

Upgrading the #Hockeypuck #openpgp #keyserver in-place has historically not been a smooth experience. In particular, the search indexes are only updated on write during normal operation, and the database schema is not updated at all. When major changes are made to the back end code, the dataset therefore has to be dumped and reloaded. This requires double the disk space and adds to the burden of maintaining a keyserver.

In preparation for #rfc9580 and #pqc keys, we have been working on in-place migrations for the search indexes and database schemas. The hockeypuck master branch now reindexes search terms transparently on startup, which will ensure consistent search results after any changes to the indexing policy. We are also testing a feature to reload the full dataset in-place after an upgrade, which must be run in offline mode due to concurrency limitations, but should otherwise be seamless and does not affect resource usage. Together these changes will reduce the maintenance burden for keyserver operators, and smooth the path for future upgrades.

In-place post-upgrade migrations, plus improved sync resilience, and hopefully a few additional improvements (watch this space!), will be available in the forthcoming 2.3 release, which is generously supported by @NGIZero Core.

First steps towards more robust sync!

#Hockeypuck’s dataset normalisation rules (or “filters”) were updated between v2.1 and v2.2, meaning that #SKS recon did not work between #openpgp #keyservers running the older and newer versions. The keyservers could not all be updated simultaneously, and a few keyservers still run v2.1 today for compatibility reasons, so we had to find a way to prevent the network from split-braining.

The quick and dirty solution was a small script that runs on each side of the filter discontinuity, polls for local changes, and submits them to the other side over HKP (the protocol your #PGP client uses). But this is effectively the same idea as the old PKS sync model, just over HTTP(S) instead of email. And sks-keyserver used to support PKS-over-email, so shouldn’t hockeypuck be able to do PKS-over-HTTP natively?

The short answer is, it can! It was long intended for hockeypuck to support PKS email, but only a fraction of the necessary code was written, and there were no tests. Today, the pgpkeys test swarm has just performed its first sync using the completed PKS code, which supports *both* HTTP and email transport.

It’s not ready for production yet though. Further testing is required, and then the second part of the PKS code can be written: automatic failover from SKS to PKS when filter mismatch is detected (and just as importantly, automatic fail*back*).

This will mean that keyserver operators will be able in the future to upgrade across filter discontinuities without risking a split brain scenario. It should also mean that key updates submitted to the hockeypuck network could be automatically synced to @keys_openpgp_org … watch this space! 😎

(Hockeypuck v2.3 development is kindly supported by @NGIZero Core)

I sometimes talk to our Roomba, now.
Along the lines of -

"You were written in C# by 23 year olds weren't you."

#software #robotics #modernsoftware #werealldoomed #bumpbump #roomba #vacuumrobot #disc #hockeypuck #ultenic

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
• Improved multithreading safety
• Deletion of personal data from hard-revoked keys
• Admin deletion of keys via signed submissions
• Detached revocation certificate support

# Bugfixes

• Missing direct key signature validation
• Missing subkeys with v3 sbinds
• Missing CORS headers
• HTTPS binding errors
• Many cosmetic improvements

# Deprecations

• SKS-keyserver recon compatibility
• UAT image packets
• User deletion and replacement of keys via `/pks/delete` and `/pks/replace` endpoints

More information: https://github.com/hockeypuck/hockeypuck/wiki

#gpg #gnupg #hockeypuck #openpgp #pgp #keyserver #sks

Latest #hockeypuck test swarm update: branch-2.2 is nearly ready for beta testing, one last round of dump and restore testing remaining in alpha before it's ready to be shared with the other operators (barring unforeseen glitches).

Hockeypuck 2.1 has issues with eventual consistency, due to its permissive schema validation that enables sks-keyserver compatibility, but also allows for various inconsistencies to propagate through the system unchecked ("key churn"). Hockeypuck 2.2 mitigates this by imposing additional validation constraints (at the expense of sks-keyserver compatibility):

"drop:unparseable"

Self-explanatory! Unparseable and malformed packets are dropped from the dataset with extreme prejudice. These are the most significant source of churn.

"drop:structuralMartian"

Signatures in an invalid place, such as subkey binding signatures over UserIDs, or UserID certifications directly on a primary key, are dropped. Most wild Martians are due to historical bugs in various implementations but have persisted on the keyservers.

"drop:implausible"

Implausible signatures are those which have an incorrect quick-hash tag in the signature header. This is a standard feature of OpenPGP that allows applications to discard (with high probability) signatures that were incorrectly calculated or misplaced, without needing to perform a full validation. Most implausible sigs are also Martians, i.e. signatures over one packet that have been incorrectly attached to a different packet - but unlike the structural Martians above, these Martians cannot be identified by their type alone, and therefore the expected digest must be calculated and compared with the quick-hash.

With these changes, we hope to be able to achieve proper eventual consistency across keyservers, allowing us to remove the current workarounds based on LRU-caching. This will give us a stable platform on which to deploy our feature updates, also planned for v2.2.

Stay tuned.

handling the storm...

#handles #hockeystick #hockeypuck #icehockey #handeyecoordination #animatedgif

handling the storm...

#handles #hockeystick #hockeypuck #icehockey #handeyecoordination #animatedgif