@16af93 @soatok why do you say coping?

If in 2026 you make generic claims against the feasibility of using #email and #openpgp for secure decentralized messaging, there hardly is a way around taking a deeper look at RFC9850 and RFC9788 and the minimalist Rust-based approach https://chatmail.at takes. Hammering away at gpg and other crimes of how email-encryption doesnt work well ... frankly does not cut it for making a generic "it can not work" claim. See also https://chaos.social/@delta/115796626066185436

Relax 😎! GPG is not OpenPGP!

Yesterday, vulnerabilities were published https://gpg.fail but they don't affect #deltachat or any other #chatmail client because

A) We never used #gnupg for anything; we use the modern #rustlang #openpgp implementation @rpgp, security audited multiple times.

B) #openpgp is fine, as modernized in #RFC9580, which already warns against several #gpgfail issues (gpg has not implemented that spec)

Please spread the word that #gpg is not #openpgp ... Thanks!

Relax 😎! GPG is not OpenPGP!

Yesterday, vulnerabilities were published https://gpg.fail but they don't affect #deltachat or any other #chatmail client because

A) We never used #gnupg for anything; we use the modern #rustlang #openpgp implementation @rpgp, security audited multiple times.

B) #openpgp is fine, as modernized in #RFC9580, which already warns against several #gpgfail issues (gpg has not implemented that spec)

Please spread the word that #gpg is not #openpgp ... Thanks!

@hko Sorry to bug you, but have you picked a license yet for your #OpenPGP project in #Rust?

Obviously your choice, but I admit I'm on a mission to advocate for more Rust software under #copyleft licenses.

Cc: @liw @nlnet

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

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

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 support

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

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.

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 support

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

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)

@hardtech @revengeday @Tutanota Just as a FYI, note that @Tutanota doesn't actually offer standard encrypted emails ( #OpenPGP, #GPG or #PGP which has been used for decades): https://tuta.com/encryption

You of course don't notice this if you only send emails between Tuta users, but if you try to send an encrypted email externally, well then the whole thing breaks down and you end up having to arrange a secure way of sending a password to the recipient: https://tuta.com/support#encrypted-emails-external

P… mais ! en plus d'être valide SPF/DKIM/DMARC/ARC les spammeurs signent leurs messages avec #OpenPGP !
#spam #mail

X-Spamd-Result: …
SIGNED_PGP(-2.00)[];
ARC_ALLOW(-1.00)[xxx.xxx:s=dkim:i=1];
DMARC_POLICY_ALLOW(-0.50)[xxx.xxx,quarantine];
R_SPF_ALLOW(-0.20)[+mx];
R_DKIM_ALLOW(-0.20)[xxx.xxx:s=dkim];
MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];

P… mais ! en plus d'être valide SPF/DKIM/DMARC/ARC les spammeurs signent leurs messages avec #OpenPGP !
#spam #mail

X-Spamd-Result: …
SIGNED_PGP(-2.00)[];
ARC_ALLOW(-1.00)[xxx.xxx:s=dkim:i=1];
DMARC_POLICY_ALLOW(-0.50)[xxx.xxx,quarantine];
R_SPF_ALLOW(-0.20)[+mx];
R_DKIM_ALLOW(-0.20)[xxx.xxx:s=dkim];
MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain];