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)

Dear Fedi friends. I want to make a short #survey to understand who actively uses #keyservers today. I am interested in understanding the meaning and the value that people attribute to keyservers nowadays, and the shift in perceptions of email #encryption

I will be making several polls (follow the thread!)

I also would be happy if some of you agree to talk with me more in depth over an e2ee encrypted channel of your choice, no need to make a call, just messages are enough

Feel free to share the polls and reach out in comments if you can and want to be part of this study.

If this ever leads to any kind of publication, I will be following the standard ethical protocol adopted in the academic research community, which is to 1. ask informed consent for quoting; 2. quoting anonymously by default, unless the person wants to be named and 3. right to withdraw from the study even after responding to the questions

QUESTION 1: DO YOU USE KEYSERVERS?

(New blog) The State of the Keyservers in 2024

“In the two and a half years since the sks-keyservers.net shutdown in June 2021, the concept of #OpenPGP #keyservers has been called into question. However, keyservers still provide a vital service to the OpenPGP ecosystem.
…
OpenPGP is one of only two widely-used cryptography standards to include a full Public Key Infrastructure”

https://blog.pgpkeys.eu/state-keyservers-2024.html

TIL the protocol everyone uses for #OpenPGP #keyservers appears to be documented only in an Internet Draft that expired about 20 years ago. Why did it never become an RFC if not an STD? Is it hiding in some hard-to-find RFC, or more-stably documented in some non-IETF place?

Just when I thought that I couldn’t possibly be more disappointed by #Python's tooling and environment, now #PyPI is no longer supporting #OpenPGP signatures: blog.pypi.org/posts/2023-05-23…

Their rationale for doing so is one of the stupidest things I‘ve ever read about OpenPGP — and I’ve read a lot of stupid takes about OpenPGP over the years!

It basically boils down to two points:

1) One-third of the public keys used “were not discoverable on major public #keyservers, making it difficult or impossible to meaningfully verify those signatures”.

2) Half of the other keys “were unable to be meaningfully verified at the time of the audit“.

On the first point: just because you can‘t find a key on keyservers doesn‘t mean the key can’t be used. Keyservers have never been the one and only way to distribute keys. Actually, the OpenPGP world has been moving away from keyservers for several years already, and most keyservers are slowly dying. The keyserver from the Sequoia-PGP folks is one of the few exceptions.

On the second point: WTF? Just because you were unable to verify to “meaningfully verify” a key doesn’t mean anything! The validity of an OpenPGP key is not something absolute that can be verified by an auditor and then held true for everybody. The entire point of OpenPGP, compared to the X.509 world, is that it is up to each individual user to verify the validity of keys (possibly using the #web-of-trust, but that’s not the only way, and actually, as for the keyservers, the OpenPGP world has been moving away from the WoT). A key that is unverified for Alice may very well be perfectly valid for Bob.