#keyserver — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #keyserver, aggregated by home.social.
-
Exciting news from the coalface! The first beta of Hockeypuck 2.4 with PQC support is now live on https://test.pgpkeys.eu for public evaluation.
#OpenPGP is going post-quantum in 2026, and the #Hockeypuck #keyserver software is prepared to distribute post-quantum-safe OpenPGP certificates.
Hockeypuck 2.4-beta1 supports post-quantum-safe signing and encryption algorithms based on ML-DSA-65, ML-DSA-87, ML-KEM-768, and ML-KEM-1024, each used in hybrid mode with either curve25519 or curve448 ECC. These are the mandatory and recommended algorithms from the upcoming OpenPGP PQC spec [1].
In order to distribute the new primary (signing) keys safely, without adversely impacting older client software, they are only distributed over the HKPv2 API. Hockeypuck implements the `certs`, `index` and `prefixlog` endpoints as defined in the latest HKP draft spec [2]. These enable upload, download, and querying of PQC-enabled primary keys.
PQC encryption subkeys using ML-KEM-768 are also distributed over the legacy HKP interface if they are attached to a v4 primary key, because these are safely ignored by #GnuPG.
(GnuPG’s “kyber” algorithms are unfortunately not supported due to interoperability issues)
Hockeypuck 2.4 development has been kindly supported by @NGIZero Core.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp -
Exciting news from the coalface! The first beta of Hockeypuck 2.4 with PQC support is now live on https://test.pgpkeys.eu for public evaluation.
#OpenPGP is going post-quantum in 2026, and the #Hockeypuck #keyserver software is prepared to distribute post-quantum-safe OpenPGP certificates.
Hockeypuck 2.4-beta1 supports post-quantum-safe signing and encryption algorithms based on ML-DSA-65, ML-DSA-87, ML-KEM-768, and ML-KEM-1024, each used in hybrid mode with either curve25519 or curve448 ECC. These are the mandatory and recommended algorithms from the upcoming OpenPGP PQC spec [1].
In order to distribute the new primary (signing) keys safely, without adversely impacting older client software, they are only distributed over the HKPv2 API. Hockeypuck implements the `certs`, `index` and `prefixlog` endpoints as defined in the latest HKP draft spec [2]. These enable upload, download, and querying of PQC-enabled primary keys.
PQC encryption subkeys using ML-KEM-768 are also distributed over the legacy HKP interface if they are attached to a v4 primary key, because these are safely ignored by #GnuPG.
(GnuPG’s “kyber” algorithms are unfortunately not supported due to interoperability issues)
Hockeypuck 2.4 development has been kindly supported by @NGIZero Core.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp -
Exciting news from the coalface! The first beta of Hockeypuck 2.4 with PQC support is now live on https://test.pgpkeys.eu for public evaluation.
#OpenPGP is going post-quantum in 2026, and the #Hockeypuck #keyserver software is prepared to distribute post-quantum-safe OpenPGP certificates.
Hockeypuck 2.4-beta1 supports post-quantum-safe signing and encryption algorithms based on ML-DSA-65, ML-DSA-87, ML-KEM-768, and ML-KEM-1024, each used in hybrid mode with either curve25519 or curve448 ECC. These are the mandatory and recommended algorithms from the upcoming OpenPGP PQC spec [1].
In order to distribute the new primary (signing) keys safely, without adversely impacting older client software, they are only distributed over the HKPv2 API. Hockeypuck implements the `certs`, `index` and `prefixlog` endpoints as defined in the latest HKP draft spec [2]. These enable upload, download, and querying of PQC-enabled primary keys.
PQC encryption subkeys using ML-KEM-768 are also distributed over the legacy HKP interface if they are attached to a v4 primary key, because these are safely ignored by #GnuPG.
(GnuPG’s “kyber” algorithms are unfortunately not supported due to interoperability issues)
Hockeypuck 2.4 development has been kindly supported by @NGIZero Core.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp -
Exciting news from the coalface! The first beta of Hockeypuck 2.4 with PQC support is now live on https://test.pgpkeys.eu for public evaluation.
#OpenPGP is going post-quantum in 2026, and the #Hockeypuck #keyserver software is prepared to distribute post-quantum-safe OpenPGP certificates.
Hockeypuck 2.4-beta1 supports post-quantum-safe signing and encryption algorithms based on ML-DSA-65, ML-DSA-87, ML-KEM-768, and ML-KEM-1024, each used in hybrid mode with either curve25519 or curve448 ECC. These are the mandatory and recommended algorithms from the upcoming OpenPGP PQC spec [1].
In order to distribute the new primary (signing) keys safely, without adversely impacting older client software, they are only distributed over the HKPv2 API. Hockeypuck implements the `certs`, `index` and `prefixlog` endpoints as defined in the latest HKP draft spec [2]. These enable upload, download, and querying of PQC-enabled primary keys.
PQC encryption subkeys using ML-KEM-768 are also distributed over the legacy HKP interface if they are attached to a v4 primary key, because these are safely ignored by #GnuPG.
(GnuPG’s “kyber” algorithms are unfortunately not supported due to interoperability issues)
Hockeypuck 2.4 development has been kindly supported by @NGIZero Core.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp -
Exciting news from the coalface! The first beta of Hockeypuck 2.4 with PQC support is now live on https://test.pgpkeys.eu for public evaluation.
#OpenPGP is going post-quantum in 2026, and the #Hockeypuck #keyserver software is prepared to distribute post-quantum-safe OpenPGP certificates.
Hockeypuck 2.4-beta1 supports post-quantum-safe signing and encryption algorithms based on ML-DSA-65, ML-DSA-87, ML-KEM-768, and ML-KEM-1024, each used in hybrid mode with either curve25519 or curve448 ECC. These are the mandatory and recommended algorithms from the upcoming OpenPGP PQC spec [1].
In order to distribute the new primary (signing) keys safely, without adversely impacting older client software, they are only distributed over the HKPv2 API. Hockeypuck implements the `certs`, `index` and `prefixlog` endpoints as defined in the latest HKP draft spec [2]. These enable upload, download, and querying of PQC-enabled primary keys.
PQC encryption subkeys using ML-KEM-768 are also distributed over the legacy HKP interface if they are attached to a v4 primary key, because these are safely ignored by #GnuPG.
(GnuPG’s “kyber” algorithms are unfortunately not supported due to interoperability issues)
Hockeypuck 2.4 development has been kindly supported by @NGIZero Core.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc
[2] https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp -
We are pleased to announce the release of Hockeypuck 2.3.3.
This is a feature-preview release that partially implements https://github.com/hockeypuck/hockeypuck/wiki/HIP-013:-In%E2%80%90Band-Metadata-Sync-Using-Trust-Packets . It also fixes a bug due to stale entries in the PostgreSQL database.
Hockeypuck 2.3.3 adds support for the enumerableDomains configuration parameter. This is a list of domains for which the keyserver will return results when queried by UserID, even if the keys have been hard-revoked (https://hockeypuck.io/configuration.html#TOC_1.3). This mitigates a regression introduced in Hockeypuck 2.2, which meant that some organizational deployments did not reliably serve hard revocations.
There are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.
Release notes can be found at https://
github.com/hockeypuck/hockeypuck/releases/tag/2.3.3Hockeypuck 2.3 development is kindly supported by @NGIZero Core
----
Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.
https://
hockeypuck.io/
https://
github.com/hockeypuck/hockeypuck -
Just n' Reminder
E-Mails von mir tragen ein #OpenPGP Zertifikat mit sich.
(Signiert, wenn ich den Ksy des anderen nicht habe)Den PGP-Key könnt ihr auf https://njbraun.de oder eurem #Keyserver eures Vertrauens checken.
Ich frage euch weder nach Kreditkartendaten, Passwörter o.ä.
[Mittlerweile solltet ihr @matrix als first Choice ansehen siehe Profilbeschreibung "Über"].
-
We are pleased to announce the release of Hockeypuck 2.3.2.
Hockeypuck 2.3.2 is primarily a bugfix release to revert a cryptographic policy default in go 1.24 that rendered some historical keys unverifiable. It also fixes some papercuts in the build process and improves the efficiency of database cleanup.
* Permit small RSA keys (reverts go 1.24 policy to that of 1.23)
* Clean more than one database entry per hashquery
* Use apt-get instead of apt in build scripts
* Match go patch versions between Dockrfile and go.modThere are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.
Release notes can be found at https://github.com/hockeypuck/hockeypuck/releases/tag/2.3.2
Hockeypuck 2.3 development is kindly supported by @NGIZero Core
----
Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.
https://
hockeypuck.io/
https://
github.com/hockeypuck/hockeypuck -
We are pleased to announce the release of Hockeypuck 2.3.1.
Hockeypuck 2.3.1 is primarily a bugfix and maintenance release:
* Fix broken delete-keys helper script
* Bumped dependencies and refactored redundant code paths
* Improved PKS support
* Config parameter to increase the number of results returned from a searchThere are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.
Release notes can be found at https://
github.com/hockeypuck/hockeypuck/releases/tag/2.3.1Hockeypuck 2.3 development is kindly supported by @NGIZero Core
----
Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.
https://hockeypuck.io/
https://github.com/hockeypuck/hockeypuck -
Die Vorbereitung hat - quasi als Live-Test - geklappt. Meine "formale" Mailadresse sendet jetzt von allen Geräten mindestens mit #PGPSignatur und ist über #Keyserver und #WKD auffindbar.
Ab Neujahr geht's dann los mit meinem Versuch ... 🙂 -
🚨 Let's build YET ANOTHER #keyserver because the world surely needs one more! 🙄 With a sprinkle of magical transparency logs, we’ll save humanity from the potential apocalypse of malicious keys. It's sure to revolutionize the way nobody cares about keyservers! 🔑✨
https://words.filippo.io/keyserver-tlog/ #transparencylogs #cybersecurity #innovation #techhumor #open_source #HackerNews #ngated -
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. -
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. -
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. -
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. -
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. -
We are pleased to announce the release of Hockeypuck 2.3.
Hockeypuck 2.3 is primarily a technical-debt release, but also adds features to ease the upgrade process in a production environment:
* Updates to the PostgreSQL table schemas
* Offline, in-place reload of all key material
* Online reindexing of table schemas
* PKS supportThere are no breaking changes between the 2.2 and 2.3 branches, and SKS sync is supported between 2.2 and 2.3 peers.
Release notes can be found at https://github.com/hockeypuck/hockeypuck/releases/tag/2.3
Hockeypuck 2.3 development is kindly supported by @NGIZero Core
----
Hockeypuck is a modern synchronising #OpenPGP #keyserver that is optimised for ease of deployment, particularly in containerised environments via docker-compose.
https://hockeypuck.io
https://github.com/hockeypuck/hockeypuck -
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!
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!
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!
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!
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)
-
#PGPainless Ecosystem Release Marathon
✅ PGPainless 2.0.0
✅ SOP-Java 14.0.1
✅ Cert-D-Java 0.2.3
✅ Cert-D-PGPainless 0.2.3
✅ WKD-Java 0.1.3
✅ VKS-Java 0.1.4 -
#PGPainless Ecosystem Release Marathon
✅ PGPainless 2.0.0
✅ SOP-Java 14.0.1
✅ Cert-D-Java 0.2.3
✅ Cert-D-PGPainless 0.2.3
✅ WKD-Java 0.1.3
✅ VKS-Java 0.1.4 -
#PGPainless Ecosystem Release Marathon
✅ PGPainless 2.0.0
✅ SOP-Java 14.0.1
✅ Cert-D-Java 0.2.3
✅ Cert-D-PGPainless 0.2.3
✅ WKD-Java 0.1.3
✅ VKS-Java 0.1.4 -
#PGPainless Ecosystem Release Marathon
✅ PGPainless 2.0.0
✅ SOP-Java 14.0.1
✅ Cert-D-Java 0.2.3
✅ Cert-D-PGPainless 0.2.3
✅ WKD-Java 0.1.3
✅ VKS-Java 0.1.4 -
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.
-
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.
-
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.
-
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.
-
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.
-
Ah, yes, the Linux Kernel's #PGP Web of Trust—because nothing screams "cutting-edge technology" like a system built on the tattered remains of #keyserver networks 🤦♂️. Who needs simplicity when you can have a Byzantine key repository maintained by a single guy named Konstantin? 🔐🔑
https://blog.kleine-koenig.org/ukl/the-linux-kernels-pgp-web-of-trust.html #LinuxKernel #WebOfTrust #Security #Technology #Humor #HackerNews #ngated -
Heutiger Aha-Moment: #PGP-Key-Verteilung über die eigene #Webseite, komplett ohne zentralisierte #Keyserver o.ä. - sehr schön! Gleich eingerichtet. ✅
Macht Ihr auch mit?https://blog.mister-muffin.de/2025/03/31/til-openpgp-web-key-directory/
-
Yo #infosec folks: I've *always* been on the fence about publishing my #pgp / #gpg / #gnupg public key, because I don't want spam from bots trawling the public #keyserver. Those of you who've posted your keys, would you say you get more spam or no difference?
-
Ahora si vemos como subir las Claves GPG para poder compartirla
-
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` endpointsMore information: https://github.com/hockeypuck/hockeypuck/wiki
-
Anyone familiar with writing database queries and want to help #mailvelope #openpgp #keyserver work with #ferretdb instead of non-free #mongodb ?
https://github.com/mailvelope/keyserver/issues/142#issuecomment-2117988302
Background: mailvelope keyserver is the only openpgp keyserver software I found that supports key removals and GDPR-compliant/abuse resistant (the commonly used keys.openpgp.org software hagrid is not supported for outside deployments).
All older key server software don't do email verification and cannot remove keys.
-
Latest #openpgp #keyserver update: key-server.org is back in good sync with the rest of the network. This brings the total of well-oiled synchronising keyservers up to 21.
-
@anarchopunk_girl @fla @Mer__edith @signalapp
Also #Signal collects #PhoneNumbers which are hard if not illegal to obtain anonymously depending on one's juristiction and those ain't even #TechnicallyNecessary unlike #Apps that do #E2EE with #OpenPGP on #SMS where it makes sense to offer people the convenience of a #Keyserver offered by the maintainers.
Personally, #Signal has a stench closer to #ANØM / #OperationIronside / #TojanShield than #EncroChat IMHO...
https://en.wikipedia.org/wiki/ANOM -
@anarchopunk_girl @fla @Mer__edith @signalapp
Also #Signal collects #PhoneNumbers which are hard if not illegal to obtain anonymously depending on one's juristiction and those ain't even #TechnicallyNecessary unlike #Apps that do #E2EE with #OpenPGP on #SMS where it makes sense to offer people the convenience of a #Keyserver offered by the maintainers.
Personally, #Signal has a stench closer to #ANØM / #OperationIronside / #TojanShield than #EncroChat IMHO...
https://en.wikipedia.org/wiki/ANOM -
@anarchopunk_girl @fla @Mer__edith @signalapp
Also #Signal collects #PhoneNumbers which are hard if not illegal to obtain anonymously depending on one's juristiction and those ain't even #TechnicallyNecessary unlike #Apps that do #E2EE with #OpenPGP on #SMS where it makes sense to offer people the convenience of a #Keyserver offered by the maintainers.
Personally, #Signal has a stench closer to #ANØM / #OperationIronside / #TojanShield than #EncroChat IMHO...
https://en.wikipedia.org/wiki/ANOM -
⚠️ #OpenPGP main public #keyserver https://keys.openpgp.org/ is #down!
Who has any news, please? :spock_pensando: -
Have united all my notes about #GPG ( #PGP ) into 1 #blog , It covers:
- creation
- modification
- #backup
- #publishing
- use
- #signature of #keys that belong to others
- #SSH #authentication #keys
- use of integrated #Yubikey #smartcard
- #notes
- #reference sources
- D’Artagnan story
Hope this will help some and.. In case you spot some imprecision or error, please please, do point it out! :ablobderpy:
https://furayoshi.com/blog/gpg-guide
#security #Linux #keyserver #code #programming #2FA #cyberSecurity #Encryption #GnuPG -
## Two Dixie Cups and a piece of string
### Oh my goodness\!
Okay first of all, I use #Matrix and #Jabber - #XMPP w/ #OMEMO, primarily.
I typically don't even regularly give out my email address nowadays, and more and more over the past four years or so, find myself publishing a #Fediverse address for myself too as a contact point.
Most often, if you ask me for my #email address I'll give you my Matrix address.
If someone wants to email me then I figure they can get that from my #PGP fingerprint or #Keyoxide.
If they don't know what a #keyserver is or where any of them are located then I just figure they're to dumb to use email.
Yes. As a technologist, I'm at times, rather arrogant, opinionated, discriminatory, and condescending... But only sometimes. The rest of the time I'm patient, attentive, empathetic, and accommodating.
Basically, if i know you don't know shit I'm a nice guy, yet if you pretend to be an all that jazz hipster know it all, then it's quite likely you'll find that I'm pretty much a full on dikhed. Spelled just like that too.
Beginning in the later eighties I think, and then the nineties they called us #BOFH. That's an acronym for someone who might already have forgotten more than you will ever know. I knew a few old Mainframe engineers with Honeywell and IBM when I was a young programmer - those guys were Gods and could tell you how many wraps of copper to make around a toroid if you had an emergency and needed to make an in the field replacement of your memory - Gods. #SuperFreakyGeeks, having already, back then, forgotten more than you or I will ever know.
They called me #Whizkid, coz I was learning shit that they were never gonna bother with - they're gonna retire soon in Mexico with boats, babes, and beers.
But I digress. I do that.
### Back to secure communications...
When it comes to Signal, I know a lot of you really like it. I have little use for it. It bleeds my DID and farms everyone's contact databases - "bing! Ex stalker bitch girlfriend just joined signal. Say hello!" What the fuck?
Well I guess she's still got me in her contacts lolz. Fuckin' bitch.
### Ummm... Yeah I'll pass.
I actually only use Signal with people who already have my #DID (phone number) anyway.
Recently, a colleague flew a cray cray route to Thailand, via #LAX to #NYC, then #Qatar. Signal works on jetliner's #WiFi too, and isn't dependant on cellular services.
Good choice, but I'm still wondering why his "safety number" changed after he departed #New_York and before arriving in #Thailand - he neither reinstalled nor switched to a new device. But that's another matter.
Sounds a little cloak & dagger fishy to me.
Anyway, I hadn't actually used #Signal in a while, and left it muted for a few months.
To my surprise... #Stories! Yay! Stories!
Wait, what are Stories? You mean like #YouTube or #InstaSPAM? And I'm assuming like they have in #Whaaaasup (never used it, never will)?
Ummm... I just tucked that little nugget of, I guess, good news away, not really knowing even how to process news of the introduction of such a useless fucking feature.
Until now.
Without further adieu, I defer to @how , one of our more prominently distinguished members in the Fediverse community, for his novel, clever, and appropriate recommendation:
https://ps.s10y.eu/@how/109308591992363124
#tallship #FOSS #communications #privacy #shenanigans
⛵
.
-
## Two Dixie Cups and a piece of string
### Oh my goodness!
Okay first of all, I use #Matrix and #Jabber - #XMPP w/ #OMEMO, primarily.
I typically don't even regularly give out my email address nowadays, and more and more over the past four years or so, find myself publishing a #Fediverse address for myself too as a contact point.
Most often, if you ask me for my #email address I'll give you my Matrix address.
If someone wants to email me then I figure they can get that from my #PGP fingerprint or #Keyoxide.
If they don't know what a #keyserver is or where any of them are located then I just figure they're to dumb to use email.
Yes. As a technologist, I'm at times, rather arrogant, opinionated, discriminatory, and condescending... But only sometimes. The rest of the time I'm patient, attentive, empathetic, and accommodating.
Basically, if i know you don't know shit I'm a nice guy, yet if you pretend to be an all that jazz hipster know it all, then it's quite likely you'll find that I'm pretty much a full on dikhed. Spelled just like that too.
Beginning in the later eighties I think, and then the nineties they called us #BOFH. That's an acronym for someone who might already have forgotten more than you will ever know. I knew a few old Mainframe engineers with Honeywell and IBM when I was a young programmer - those guys were Gods and could tell you how many wraps of copper to make around a toroid if you had an emergency and needed to make an in the field replacement of your memory - Gods. #SuperFreakyGeeks, having already, back then, forgotten more than you or I will ever know.
They called me #Whizkid, coz I was learning shit that they were never gonna bother with - they're gonna retire soon in Mexico with boats, babes, and beers.
But I digress. I do that.
### Back to secure communications...
When it comes to Signal, I know a lot of you really like it. I have little use for it. It bleeds my DID and farms everyone's contact databases - "bing! Ex stalker bitch girlfriend just joined Signal. Say hello!" What the fuck?
Well I guess she's still got me in her contacts lolz. Fuckin' bitch.
### Ummm... Yeah I'll pass.
I actually only use Signal with people who already have my #DID (phone number) anyway.
Recently, a colleague flew a cray cray route to Thailand, via #LAX to #NYC, then #Qatar. Signal works on a jetliner's #WiFi too, and isn't dependant on cellular services.
Good choice, but I'm still wondering why his "safety number" changed after he departed #New_York and before arriving in #Thailand - he neither reinstalled nor switched to a new device. But that's another matter.
Sounds a little cloak & dagger fishy to me.
Anyway, I hadn't actually used #Signal in a while, and left it muted for a few months.
To my surprise... #Stories! Yay! Stories!
Wait, what are Stories? You mean like #YouTube or #InstaSPAM? And I'm assuming like they have in #Whaaaasup (never used it, never will)?
Ummm... I just tucked that little nugget of, I guess, good news away, not really knowing even how to process news of the introduction of such a useless fucking feature.
Until now.
Without further adieu, I defer to @how , one of our more prominently distinguished members in the Fediverse community, for his novel, clever, and appropriate recommendation:
RT: https://ps.s10y.eu/users/how/statuses/109308591992363124 -
Mastodon Konto verifizieren mit GPG
Mittels Keyoxide kann eine dezentrale sichere Online-Identität gebildet werden, die sich beispielsweise zur Verifizierung eines Mastodon Accounts eignet.
#Mastodon #Verifikation #Verifizierung #GPG #Keyserver #Keyoxide #neuhier #Linux
-
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
@nsa @Jain You can also validate it with the public key which is also in the #KeyServer :blobcatgendou:
keys.open...
-----BEGIN PGP SIGNATURE-----
iLMEAQEKAB0WIQT3b7sqZuPnD91mL6CESxETh1VGHgUCY4jhKgAKCRCESxETh1VG
HjEWBACcVsQ7H/mzENbH8OuANXaKIK/9WqquSfhRpSIekjKrs50at13CwIlcusd9
fS7sBwAlh6betsqGfBtw+/4Z6VBS1EjEU84ANc7JkGu8hTuhp1LIgsqwBWlrdEtJ
7MnouJrZGVcD7v/c0+vxnG7zpJ3eRiDczz50uILICmcLry7lzA==
=GtbW
-----END PGP SIGNATURE----- -
#HomeLab question; after figuring out why I couldn't connect to my server the other day I'm looking for a solution. Like a responsible person I've installed my server with #FullDiskEncryption but that means manual intervention after a reboot (namely entering the decryption password).
Automatic updating also means regular reboots, but I don't want to deal with the password. I've heard a #keyserver might be a solution, but I hope there are other solutions available?
-
@dcent
We are not seeing the other half? Only this post.1) Sounds good.
2) There's no point talking to a bank about investments and loans if communications are leaky. Imagine communicating re a possible #homeLoan and Google/M$/Blackrock, seeing that an using that info against you.
We need secure comms. Therefore banks should use/store ppl's public encryption keys. They need to act as a #keyserver also, because a) there's not enough good #keyservers, b) also stops ppl knowing where yu #bank.
