A nice thing about #Manjaro is that it holds back updates for a week. I see Manjaro haters roll out this fact like it's a bad thing. Whatever. Here's the "fun" part of all this: I didn't need to do it. The problem isn't #Majaro, there's something wrong with #Arch mirrors and #keyservers. Huge swaths of the mirrors are inaccessible. Keyservers are also often unavailable. Why? Who the fuck knows. So, I have a tarted up Arch install that may or may not update correctly. Oh, and I installed KDE because connecting to a sever to download something else wasn't working at the time. That's my #Linux Spring Adventure. 4/4

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?